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
Alvin, > > Normally, you houldn't neeed the divide by 2 and cable stub: just use the > fact that DCMs align to the rising edge and use their CLK180 to clock your > data in. Without the divide by two to strip the phase modulation, I think the duty cycle variation might drive the DCM's batty, as it's well outside the allowed DCM input clock duty cycle and cycle-cycle jitter specs. BrianArticle: 89776
GPE wrote: > But - I have an oddball case of a clock. One always runs at 1Khz. The > other *May* run as fast as 100MHz but usually runs slower -- sometimes as > slow as 100Hz. If I knew my variable clock was always fater than the 1KHz > clock, the edge detection would work fine. > > Incidently, I already have a circuit similar to what you have in one of my > other designs which does have a guaranteed fast clock. > > Thanks, > Ed > > "Stephan Flock" <sflock@freenet.de> wrote in message > news:dh354s$gcu$03$1@news.t-online.com... > > You could run both your 32-bit counter and the other set of registers off > > a > > fast (e. g. 100 MHz) clock. Detect the edge of the 1 kHz counter clock > > signal and make it a clock enable for the counter together with the 100 > > MHz > > clock. > > > > HTH, > > Stephan > > > > The obvious solution would be to use a third clock of known higher frequency. If this isn't avaliable, you could add hardware to detect which clock is running faster, but that may be more work than it's worth, especially if your variable rate clock changes frequently. This would be a good time to add 2 cents worth on the virtues of having a free-running clock in an FPGA (as were in early Xilinx parts). Many newer parts have internal oscillators for configuration but the clocks aren't available to the routing fabric. I've seen some threads here about building oscillators in the FPGA from internal LUT delays and the like. I wouldn't like to depend on that sort of design due to variances in process and temperature. For future designs, however I would suggest always having a fixed clock of sufficient frequency to feed a DLL (unless you can't afford the crystal which would be unusual in most designs containing an FPGA). Regards, GaborArticle: 89777
Julian Kain wrote: > Greetings, > > I am implementing a design whose system clock is generated by an MGT > (the TXOUTCLK pin), based on higher frequency differential reference > clock inputs to that MGT. The frequency generated at TXOUTCLK is > correct, but the issue is that Xilinx ISE (7.1i, SP4) does not route > this clock as a CLK Net. > > The particular error, generated after PAR, is "WARNING:Route - CLK Net: > net_name may have excessive skew because xx NON-CLK pins failed to > route using a CLK template." > This error message usually means there are non-clock loads in the design. This can happen when the clock signal is used as a gate (LUT) input. Normally in a fully synchronous design only clock or latch gate inputs of the CLB or IOB would connect to the clock route. If you have the FPGA editor I would suggest looking at the post place-and-route design and see how the clock was actually routed. If it uses global resources for all of the clock loads and only local resources for gated loads you may actually have lower skew to the important loads than reported. If you are actually gating this clock to deliver to some clocked loads, you should try to change the design to use clock enables rather than gated clocking. > This design cannot tolerate the max skew that is reported (about 20% of > a period), or the resulting max delay of about 40%. How can I force > this net to use the CLK template I specified in the UCF, or otherwise > remedy this issue? > > Thanks much, > Julian KainArticle: 89778
IMHO another big issue with "compiler" approaches is memory management. Given the variety and flexibility available in hardware, it is very hard to determine the right memory organization and chaching strategy. Significant performance losses would follow in memory-bound applications.Article: 89779
Hi group, I am trying to download the design compiled with quartus II 5.0sp1 web edition into MAX II chip EPM1270T144C5. However, quartus programmer complained "Error: Unexpected error in JTAG server -- error code 84" I used the same MAXII board, cable (JTAG from parallel port) and computer days ago with quartus II 4.2 web edition and had no problem to download. Unfortunately I deleted quartus 4.2 web edition. Can anybody tell me what this error code 84 is? I googled but get no answer. Thank you! vax, 9000Article: 89780
Adam, It was pointed out to me the other day, that Neocad reverse engineered bitgen. They never reverse engineered the bitstream (had no idea what controlled what). Folks are ofthen fond of saying "there is no security in obscurity" but then they do not have to search for a needle in a haystack. Keeping the bitstream secret is still a powerful means of preventing reverse engineering. Lately I asked a well know reverse engineering firm to do their job, and tell me what the design was given only the bitstream. They no bid the job "as we felt it would take to long, and cost too much." That definitely surprised me, as to refuse business for something that is understandably long and arduous (read $$$) was a surprise. But from their point of view, they would much rather go after something that was easier (cut, section, etc.) and had immediate payback. Now it is said that governments would not be so limited (they would reverse engineeer a bitstream). Very few of our customers are worried about a governement stealing their designs and intellectual property. For those that are (other governments), we are happy to assure them that the bitstream still remains a secret (for what that is worth, which may in fact be a lot). So far the 'Logic Vault' cards I have sent out to academia have not been able to be cracked by DPA (a commonly held belief is that differential power attack (DPA) is able to 'crack' 3DES or AES easily). Seems that finding the keys in a smart card may be a junior EE class exercise, but going after something a bit more challenging (like the keys held in out battery backed RAM) is no easy task. I'd like to think that it has to do with brilliant engineering, but it is more likely that one can not discern the information from the noise of all those pesky support transistors that clutter up a FPGA. Austin Adam Megacz wrote: >>Some one already told me "Jbits is dead" but didn't explain why ! > > > Because http://www.megacz.com/research/bitstream.secrecy.xt > > - a >Article: 89781
Hi I have some more insights in the problem connecting a "xilinx xup virtex II pro" board with linux: I just installed windows and ise71_4i and connected the board. After *three* times driver installation the board worked. Then i rebooted into linux and got impact running and identifying the chips in the jtag chain. After that i powercycled the board loading the firmware via linux into the board. After that the board stopped working. To double check i booted into windows (without switching the xup board off) and got the same problems as under linux. So the problem seems to be related to the firmware or the loading of the firmware. It would be really nice to get a firmware which gets the XUP board working. The revision of the board is 3 (anyone a different rev and got the board working under linux?) Thanks STArticle: 89782
Can the downloading of the bit file be done w/out using an embedded processor or EPROM/PROM as we are just trying to program the device autonomously. This is not going into production so i dont have to worry about loosing the configuration data in case of power loss. AnujaArticle: 89783
following is a part of the state machine im trying to design. when start is set to '1' it goes to rw_1. when in that state, i increment the ram_counter_w and jumps to rw_2 , where the values of ram_counter_w is checked. if it is "11111111111111110", i jump to rw_3 , otherwise i come back to rw_1. The problem is i never go to rw_3. i continuously alternate between rw_1 and rw_2. Since im very new to VHDL and FPGA development, i cant find the problem. please someone help me. Thank you CMOS --------------------------------------------------------------------- type state_type is (ready, rw_1, rw_2, rw_3); signal state, next_state : state_type; signal ram_counter_w : std_logic_vector(17 downto 0); begin process ( state, ram_counter_w) begin next_state <= state; case state is when ready => if reset = '0' and start = '1' then next_state <= rw_1; else ram_counter_w <= "000000000000000000"; end if; when rw_1 => ram_counter_w <= ram_counter_w + 1; next_state <= rw_2; when rw_2 => if ram_counter_w = "11111111111111110" then next_state <= rw_3; else next_state <= rw_1; end if; when rw_3 => -- some statements... when others => -- some statements end case; ---------------------------------------------------------------------Article: 89784
Austin Lesea <austin@xilinx.com> writes: > It was pointed out to me the other day, that Neocad reverse engineered > bitgen. They never reverse engineered the bitstream (had no idea what > controlled what). Austin, please cite a source for this. Xilinx would have sued them halfway to the moon if their product required "bitgen.dll" (or equivalent) from the Xilinx ISE in order to function. That would be clear infringement on Xilinx's copyrights and any judge would have been more than happy to hand down an injunction putting them out of business. - aArticle: 89785
My first suggestion would be to declare the counter as an integer first
so that the increment ('+') operation is more effective. Also the you
can not use an IF statement to check a std_logic_vector since you would
need to compare every single bit. Integer is easier to do so.
I gather this is an asynchronous state machine. There is no process
for the clock. In this case you would only change states during each
clock, and not on every time a bit changed as in your above example.
Article: 89786Just in case, I have done the following to confirm that Modelsim guarantee's does not find the library file: 1) I inserted the altera_support_vhdl.vhd file into my Modelsim project 2) I compiled the .vhd file which created what I believe to be the library itself into the default "work" library for my project. 3) Recompiling the SOPC.vhd file produced the same error and it says that it still doesn't find that library.Article: 89787
Hi all,
I am trying to create LVDS, bidirectional, DDR I/O pads
in a Spartan-3E chip (xc3s500e).
I've created an I/O pad in VHDL which simply instatiates
and connects Xilinx library components:
* IOBUFDS = bidirectional, differential I/O pad,
* IDDR2 = S3E input DDR logic,
* ODDR2 = S3E output DDR logic,
Tri-State control is not DDR - I've added a simple FF
instance.
The pad matches a subset of the S3E description of the
I/O pad logic.
When I try to implement a chip using these I/O pads, the synthesis
and Translate stages complete without errors, but the Map stage
outputs the following error for each I/O Pad:
ERROR:Pack:1564 - The dual data rate register
Data_Pad/IO_Pad6/Out_DDR_Reg/Data_Pad/IO_Pad6/Out_DDR_Reg/ODDR2.C0D1
failed to join the DIFFSI component as required. Symbol
Data_Pad/IO_Pad6/Out_DDR_Reg/Data_Pad/IO_Pad6/Out_DDR_Reg/ODDR2.C0D1
is not a kind of symbol that can join a DIFFSI component.
>From what I've been able to find, the DIFFSI is the "negative"
pin of the I/O pad - the I/O logic is placed at the "positive"
pad, but borrows resources from the negative pad, which can't
be used for anything else.
The error is connected to having bidirectional pads; when I used
separate input and output pads, there were no errors.
There is no difference in the errors when I place LOC constraints
on the positive, negative, both or none of the I/O pads.
The IDDR2 and ODDR2 have Generic options to control clock
alignment, some of which borrow FFs from the negative pad;
changing these Generics make no difference in the errors.
I am using ISE7.1i, SP4 (problem appeared in SP3 as well).
The Xilinx knowledge base doesn't have anything about this error.
Anyone knows what is the problem and if there is any way to
fix it? please help, I am getting pretty desperate (need to
start board layout).
Thanks in Advance
Article: 89788Hello Manusha, I looked over your code and ran a simulation using the waveform tool in the Xilinx Webpack. Some things: 1) You have no clock which is something I have never tried. Usually, VHDL is synchronous and you will see: your_name : process(clk) begin if( clk'event and clk='1') then starting most of your work. 2) You need a reset in your sensitivity list and an end process at the end of your process. 3) After simulating your code, your process never comes out of the the RESET state. Perhaps this is because next_state is not in your sensitivity list. You can try to put next_state in your sensitivity list, instead of state, but I don't know if that will solve your issues. Good luck, Brad Smallridge P.S. Here is the code I ran: library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity top is port( reset : in std_logic; start : in std_logic; state3 : out std_logic ); end top; architecture Behavioral of top is type state_type is (ready, rw_1, rw_2, rw_3); signal state, next_state : state_type; signal ram_counter_w : std_logic_vector(17 downto 0); begin process (reset, state, ram_counter_w) begin next_state <= state; state3<='0'; case state is when ready => if reset = '0' and start = '1' then next_state <= rw_1; else ram_counter_w <= "000000000000000000"; end if; when rw_1 => ram_counter_w <= ram_counter_w + 1; next_state <= rw_2; when rw_2 => if ram_counter_w = "11111111111111110" then next_state <= rw_3; else next_state <= rw_1; end if; when rw_3 => state3 <= '1'; -- some statements... when others => -- some statements end case; end process; end Behavioral;Article: 89789
codejk wrote:
> I tried to find some external dpram chips
> for several days, but I couldn't.
>
> The spec. of dpram which I need is:
> port a addr 10bit
> port a data 8bit
> port a we
> port a clk
> port b addr 10bit
> port b data 8bit
> port b clk
>
> That's all.
> Could you please recommend one?
Consider using a standard RAM
and designing your own dual port
controller on the fpga.
-- Mike Treseler
Article: 89790Adam, The things you learn after you buy a company. Personally, I think it was for the best that we purchased Neocad... Austin Adam Megacz wrote: > Austin Lesea <austin@xilinx.com> writes: > >>It was pointed out to me the other day, that Neocad reverse engineered >>bitgen. They never reverse engineered the bitstream (had no idea what >>controlled what). > > > Austin, please cite a source for this. > > Xilinx would have sued them halfway to the moon if their product > required "bitgen.dll" (or equivalent) from the Xilinx ISE in order to > function. That would be clear infringement on Xilinx's copyrights and > any judge would have been more than happy to hand down an injunction > putting them out of business. > > - a > >Article: 89791
Gabor wrote: <snip> This would be a good time to add 2 cents worth on the virtues of > having a free-running clock in an FPGA (as were in early Xilinx > parts). Many newer parts have internal oscillators for configuration > but the clocks aren't available to the routing fabric. I've seen > some threads here about building oscillators in the FPGA from > internal LUT delays and the like. I wouldn't like to depend on that > sort of design due to variances in process and temperature. However, those variances actually self-track, so a Logic Element + Routing derived clock can be self-margining. Lattice have added a usable clock to their MachXO, so this might catch on.... > For future designs, however I would suggest always having a fixed clock > of sufficient frequency to feed a DLL (unless you can't afford the > crystal which would be unusual in most designs containing an FPGA). There is another class of Osc, called the Calibrated On Chip - these are now common in small Microcontrollers, and achieve in the regions of 1-2-3% stability over Vcc and Temp. Ideal would be both; The first type would be easy for the FPGA vendors to offer as simple IP blocks, but the CalOsc is needs special HW, and a mindset change in the FPGA sector, so is less likely..... -jgArticle: 89792
I have a working design where I can see the ouput on the leds .I am using a ML310 board . The design doesnt seem to work when I try to load it through chipscope pro. When I use a ILA core into my design and try to load the design on to the system it always says that "Waiting for Core to be armed, slow or stopped clock": I saw the chipscope pro answer record which says that this is due to clock.But I am giving system clock in the core inserter module. Instead of system clock if I give JTAg clock as the clock in the inserter module then the chipscope output remains static with all constant waveforms. Did anyone have a similar problem? NiteshArticle: 89793
To all,
I did a bit of poking around in Modelsim, and I figured it out.
Just so you know what I did to figure this out, here's the steps:
1) I copied the altera_vhdl_support.vhd file into my Modelsim directory
2) I clicked on the library tab
3) I right-clicked and selected New Library, and created a new library
called: "altera_vhdl_support"
4) In the project window I added the VHDL file for the
altera_vhdl_support and right-clicked this file, to go to the compile
properties, where I forced the compiled library into the
"altera_vhdl_support" instead of the default work directory.
Once I did this, and re-compiled the SOPC builder VHDL file, it
compiled. I haven't tested it yet, but at least it compiled.
Cheers....
Article: 89794The original question has been answeed: I still stand behind my suggestion in #2 in this thread. A self-contained stable oscillator is a difficult (if not impossible) proposition. All transistor parameters have unacceptable variation over temp, voltage, and processing. Metal resistivity and capacitance are fairly stable, but how do you make an oscillator out of that? Peter AlfkeArticle: 89795
If this is a Virtex part you can try using the ICAP (Internal Configuration) Port. This allows you to have the device configure itself. It does not need an embedded processor, but you have to be careful about your bitstreams in that the new bitstream with which you are programming the device must have the same ICAP logic in the same location as the previous bitstream, else your configuration logic will change mid-stream and stop reconfiguration. You could also use partial bitstreams to avoid overwriting the ICAP control logic.Article: 89796
Peter Alfke wrote: > The original question has been answeed: I still stand behind my > suggestion in #2 in this thread. > A self-contained stable oscillator is a difficult (if not impossible) > proposition. All transistor parameters have unacceptable variation over > temp, voltage, and processing. Metal resistivity and capacitance are > fairly stable, but how do you make an oscillator out of that? > Peter Alfke Depends on what you mean by stable and acceptable. Certainly to RS232 standards is achievable today. For some background reading, look at the Philips LPC9xx family, and the Atmel AVR series. They have impressive On-Chip osc performances. Also look here (even more precise) : http://www.maxim-ic.com/products/timers/econoscillator.cfm they show Silicon Oscillators, spec'd to ~1%. and targeting ceramic resonator applications. They also have Spread spectrum Silicon oscillators. More esoteric are the still experimental 'machined silicon' oscillators - more special process handling, but precisions getting close to low end quartz crystals. There are many apps, where even 2% is more than precise enough, and others where +/-20% would be fine. -jgArticle: 89797
This worked quite well. I left my 32-bit binary counter alone (hey, I'm lazy!) -- added a binary to gray code converter on the output. Registered that using a higher clock that was used to derive the 1KHz clock - so I get a nice, registered gray code. With the higher frequency clock, I register the gray code at the required time interval. Perform a gray code to binary conversion to get back to my original value. Luckily, I have several clock periods worth of time to bring back the original binary value as this piece of the puzzle isn't real fast. Now all I have left is a 1-bit ambiguity - which is quite reasonable. Thanks, Ed "Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1127539632.607707.192720@g44g2000cwa.googlegroups.com... > If I understand you right, you need to copy the 32-bit counter ontent > (which changes very slowly) into a fast-changing (fast-clocked) > register at asynchronous times. > I am sure that your problem is not metastability, but rather timing > uncertainty between the 32 register bits. My suggestion is to run the > 32-bit counter as a Gray counter. Since only one bit changes at any > time, a not-totally-synchronous transfer never results in a serious > error. Afterwards, you can convertthe gray code back to binary. > Binary-to-Gray conversion uses one XOR per bit, and is very fast. > Gray-to-binary involves a ripple chain, and may be more challenging at > 100 MHz, but I suppose you can do it off-line. Or you pipeline the > operation. > > As is often the case,,mtastabilty gets blamed here for a completely > different (and more solvable) problem. > Peter Alfke, Xilinx Applications >Article: 89798
Peter Alfke wrote: > metastability is a problem that cannot be "solved", we can only > reduce the probability of errors due to metastability. This certainly depends on what you mean by "solved". Even machines intended to be completely deterministic are built of components which have various wear and statistical failure mechanisms. However, engineers usually consider the problem solved if the MTBF of the conglomeration of gears, relays, tubes, CMOS transistors, etc. is longer than the expected operational life of the widget by sufficient orders of magnitude. In that sense, one could easily consider the metastability problem solved when the probability of the register train not resolving is far less than that of the device getting vaporized in a direct meteor strike. In which case even a CMOS NAND gate would no longer produce the correct voltage result. > In many cases you will find that the mean-time-betwen-failure is > millions or billions of years. Which means the power supply, if not electromigration, background radiation, bonding wires, or even a meteor strike, etc., would far more likely cause any instance of the "solved" FPGA solution to fail even earlier. IMHO. YMMV. -- Ron rhn A.T nicholson d.O.t C-o-MArticle: 89799
Marco wrote: > Hallo, > I have used one core downloded from "opecores.org" into a project which > will be a commercial microcotroller. > > Which are the commercial conditions about selling it into the complete > system? > > Many Thanks > Marco Marko, you should direct this question to the OpenCores mailing list. Every developer is free to chose the license of his/her liking. Try asking the developer directly. Best Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and Synthesis ****** Certified USB 2.0 HS OTG and HS Device IP Cores ******
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