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
Hello, I should like to create a simple example for using a clkdll on Spartan 2 XC2S200 with a Expansionboard (with LEDs and Pushbuttons). I have created a circuit without DLL. This works correctly. The clockspeed is 48 Mhz. The circuit with clkdll, ibufg, bufg etc. doesn't work correctly. It seems to be, the clk2x (clkdll) dont generate a clock signal. I work with XILINX 4.2WP3. My toplevel circuit is a schematic, which was created with Xilinx ECS. There are an 16bit counter (with control logic) and an interface circuit (for the expansion board). The Clock from the counter should be the double frequency (96 Mhz). Now i try to explain my schematic: Pin GCK (p80)-> IBUFG -> CLKIN from CLKDLL -> CLK0 from CLKDLL -> BUFG -> CLKFB from CLKDLL CLK2x from CLKDLL -> BUFG -> CLK-Input from Counter. GND -> Reset from CLKDLL Constraint Implentation Editor: The conduction (from CLK2x to BUFG) is identified as an clock net. I will be glad, if anybody tell me, where is my mistake in the design. with kind regards StefanArticle: 49626
Hi all, I found a lot of EPC1 configuration EPROMs almost for free. Unfortunately I have no programmers for this device. Where can I found the programming algorithm specifications to build a simple programmer? Thank you in advance. LuigiArticle: 49627
Rinux ha scritto nel messaggio ... >Hi all >Anyone know a sinple way to program a max3000 ?? > >regard Ciao Rinux, Altera MAX3000 are in system programmable devices. The best way to program it is with a Byteblaster cable. Bye LuigiArticle: 49628
I don't think this is a metastability problem, rather it is improper use of an asynchronous design.
Metastability gets one flip-flop balancing in an unstable 'meta state' that is neither the high nor
the low state. It only occurs if the D input is changed within a very narrow window around the clock
edge. More likely, you've got an async signal feeding more than one flip-flop, so that within a
certain window around the clock you wind up with one of them interpreting the input before it
transitions and one interpreting the input post transition. This is an asynchronous synchronization
problem, which is quite distinct from metastability.
Michael S wrote:
> hmurray@suespammers.org (Hal Murray) wrote in message news:<utd7cdm3r2gsac@corp.supernews.com>...
> > >I am not familiar with the techXclusive, can you provide a URL?
> >
> > http://support.xilinx.com/support/techxclusives/metas-techX32.htm
>
> Good article. Unfortunately, it doesn't mention the temperature
> conditions for the mesurements.
>
> Recently we suffered a problem which I attribute to metastability. Our
> design fed Intel 386EX processor with asynchronous READY# signal.
> Simetimes it caused the hang up. The processor's RD# signal was
> indicating that READY# is accepted while correspondent CS# signal
> remained asserted, indicating that READY# was missed. Looks like
> classic metastability problem, doesn't it ?!
> The problem was very temperature dependent. I never did a statistical
> mesurements (was to busy to understand and resolve the problem), but
> there was at least order of magnitude difference between 0 and -20deg
> Celsius (the colder is worse).
> Theoretically, the strong temperature dependance is expectable. It
> would be fine if Xilix will provide us with temperature data.
--
--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: 49629
No, The transaction is entirely with Amazon. I get a referral fee paid to me
by Amazon at the end of each quarter. At least right now your currency is
stronger against the dollar than it has been in recent years, so you do get
something of a discount.
Noddy wrote:
> > Buy, beg, borrow or steal (well, no don't steal) a copy of P.P.
> Vaidyanathan's multirate filtering
> > book (You can buy it through the bookstore on my website, which will give
> me a kickback which in
> > turn helps to support the website).
>
> Don't suppose you give student discounts ('specially students from countries
> with a 3rd world currency) ????? :)
>
> adrian
--
--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: 49630rickman <spamgoeshere4@yahoo.com> wrote in message news:<3DD87D53.C15787CE@yahoo.com>... > > I am surprised that it got worse with temperature. Silicon delays are > less at colder temps, which in turn allows more time for metastability > resolution within any path that has a significant delay. Since you saw > more frequent failures, this either might not have been metastability or > if the metastable FF fed a path that had little delay and was mostly > slack time, the increased incidence may have been due to the gain > bandwidth being reduced at lower temps. I don't know enough about FFs > to know how this is affected by temperature. > > But I am not clear as to what you think the metastable path is. If it > is the Ready signal being presented to the 386, then the problem would > be inside the 386. So why would you be looking to Xilinx for info? It has nothing to do with Xilinx. I just brought my case as an example of the temperature dependency of the (supposed) metastability. > > In general, I would expect the effect of temperature to be small in > relation to the exponential effect of slack time. If you see a > metastable failure at *any* temperature, it is because not enough time > was provided for settling. > > -- > > 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 FAX I never studied the theory of metastable flip-flops. But intuitively I see metastable state as a very small local minimum on the energy curve. At the higher temperature the thermal noise can be strong enough to rescue the flip-flop out of this state to the stable one. It's all my speculations, may be, I erroneously apply the lows of microworld lows to the macroworld phenomenon ?Article: 49631
On 18 Nov 2002 06:43:15 -0800, already5chosen@yahoo.com (Michael S) wrote: >I never studied the theory of metastable flip-flops. But intuitively I >see metastable state as a very small local minimum on the energy >curve. At the higher temperature the thermal noise can be strong >enough to rescue the flip-flop out of this state to the stable one. >It's all my speculations, may be, I erroneously apply the lows of >microworld lows to the macroworld phenomenon ? Back when the phenomenon of metastability was first observed and discussed, some people suggested that metastable behavior could be circumvented, or at least improved, by injecting noise that would move the offending device away from its metastable point. But others pointed out that while noise might move a node out of metastability, it was equally likely that noise would move an almost-metastable node into metastability. Bob Perlman Cambrian Design WorksArticle: 49632
Hi, i was trying to synthesize a simple 4 bit up-counter using
synplify but I was returned a no matching overload for "+" for line
ctCOUNT <= ctCOUNT + "001"; Are there any libraries which i need to
include?
entity counter is
Port ( ctclk : in bit;
ctrs : in bit;
ctce : in bit;
ctld : in bit;
ctbranchaddr : in bit_vector(2 downto 0);
ctcount : inout bit_vector(2 downto 0));
end counter;
architecture Behavioral of counter is
begin
process (ctCLK, ctRS)
begin
if ctRS='1' then
ctCOUNT <= "000";
elsif ctCLK='1' and ctCLK'event then
if ctLD='1' then
ctCOUNT <= ctbranchaddr;
else
if ctCE='1' then
ctCOUNT <= ctCOUNT + "001"; --<------------------
end if;
end if;
end if;
end process;
End Behavioral;
Article: 49633nospam <nospam@please.com> wrote in message news:<ppggtu0fe816a15l2lm9db3jnc9kii30li@4ax.com>... > already5chosen@yahoo.com (Michael S) wrote: > > >hmurray@suespammers.org (Hal Murray) wrote in message news:<utd7cdm3r2gsac@corp.supernews.com>... > > I would attribute it to a duff design - the 386EX datasheets specify a > setup and hold time for the READY# input. The datasheets do not specify > what happens if READY# is not stable during that period. You experience > shows the processor can get screwed up pretty badly - but it is still your > fault. > I know it's my fault, never claimed otherwise. > The 'problem' inside the 386 is almost certainly a race and not > metastability. > Do you think 386EX uses READY# input in multiple state machines without sampling it in one FF ? If it was the case, I would expect the problem to appear much more often then it actually does. > I do wish chip manufacturers would be a bit more specific about which > violation of timing specifications can really screw up their parts. In the common case 386EX would not be screwed so badly by asynchroneous READY#. Our case is particularly bad because our peripheral (TMS320C5420 HPI) releases READY# signal immediately after seeing RD# goes up. So the next clock 386EX samples READY# it is already up. Most asynchroneous peripherals would not release READY# until both RD# and CS# are released by 386EX.Article: 49634
luigi funes wrote: > Rinux ha scritto nel messaggio ... > >>Hi all >>Anyone know a sinple way to program a max3000 ?? >> >>regard > > Ciao Rinux, > Altera MAX3000 are in system programmable devices. > The best way to program it is with a Byteblaster cable. > Bye Schematics for the download cable is available on the Altera website. ReneArticle: 49635
already5chosen@yahoo.com (Michael S) wrote: >> The 'problem' inside the 386 is almost certainly a race and not >> metastability. >Do you think 386EX uses READY# input in multiple state machines >without sampling it in one FF ? If it was the case, I would expect the >problem to appear much more often then it actually does. The timing specs for READY# and signals changing due to the completion of the cycle (which occurred because of READY#) are referenced to the same clock edge. So READY# is not synchronised with a single FF or everything would be delayed by a cycle. What READY# actually feeds I don't know but you don't need multiple state machines to race just multiple FFs which a single state machine has.Article: 49636
Hi all, I have already found some resources about FPGA implementation of MD5 hash algorithm, but I couldn't find any VHDL source code. Could anyone please help me? Thanks in advance for any assistance, Antonis.Article: 49637
"sowteng" <sowteng@lycos.com> schrieb im Newsbeitrag news:699d5bf2.0211180711.56d57bb6@posting.google.com... > Hi, i was trying to synthesize a simple 4 bit up-counter using > synplify but I was returned a no matching overload for "+" for line > ctCOUNT <= ctCOUNT + "001"; Are there any libraries which i need to > include? Yes. library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; And dont use bit and bit_vector, use std_logic and unsigned instead. -- MfG FalkArticle: 49638
"Stefan Kulke" <kulke@informatik.tu-cottbus.de> schrieb im Newsbeitrag news:arapdo$1i5$1@Maust.bbone.tu-cottbus.de... > Now i try to explain my schematic: > > Pin GCK (p80)-> IBUFG -> CLKIN from CLKDLL -> CLK0 from CLKDLL -> BUFG > -> CLKFB from CLKDLL > > CLK2x from CLKDLL -> BUFG -> CLK-Input from Counter. > GND -> Reset from CLKDLL Looks good. Try to route the reset of the DLL to an IO and reset the DLL manually a few times. Also rout the LOCKED output to an IO (a LED is nice here) to see the status of the DLL. -- MfG FalkArticle: 49639
"Bernhard Mäder" <nonuschk@gmx.net> schrieb im Newsbeitrag news:3dd7d934@news.swissonline.ch... > > > > I agree. So try a fast synchronous FIFO. > > > > Yes, but the point is that I _have_ to handle an incoming clock of unknow > frequency (up to 75MHz). Or is there any other technique that can be > applied? Peter, I gess this is an incomming call for you. ;-) ASYNCHRONOUS FIFOS!!!!! Yes, there is a way. Use gray encoded read/write pointers to transfer them over the clock boundary. Then make sure to stop writing, when the FIFO has 2..3 or less words free, NOT if there is just one word, free. Same with reading. -- MfG FalkArticle: 49640
edaudio2000@yahoo.co.uk (ted) wrote in news:c54bf83f.0211160213.723bdbaf@posting.google.com: > At a recent Xilinx seminar one of the presenters showed a slide > describing PicoBlaze and CoolBlaze simple 8 bit cores for Xilinx > products. > > Looking at the XIlinx site, I only find a mention about Picoblaze, no > mention at all about CoolBlaze. > > Google produced no results whatsoever. > > Is Coolblaze a real product? If not why was it shown on the slides? > > PS we have a need for such a product, hence the asking! > You may give a look to triscend products. I don't have any link with that company ( except a friend who works there ), but I found their idea of combining a small uc with a cpld fabric pretty cool, and prbably more efficient than a soft core in a cpld... hth, Sylvain YonArticle: 49641
"luigi funes" <fuzzy8888@hotmail.com> wrote in message news:0W5C9.11488$Ka3.344765@twister1.libero.it... > Hi all, > I found a lot of EPC1 configuration EPROMs almost for free. > Unfortunately I have no programmers for this device. > Where can I found the programming algorithm specifications > to build a simple programmer? > Thank you in advance. You can program them using a Byteblaster with a suitable socket for the EPC1, a couple of resistors and a header for the BB, mounted on a small piece of stripboard. We did this where I used to work. Leon -- Leon Heller, G1HSM leon_heller@hotmail.com http://www.geocities.com/leon_hellerArticle: 49642
> Nor is the V2Pro. It's a lateral move from the V2, > kind of like the move from Virtex to Virtex-E I have to disagree the Virtex E just a different mix of the same stuff. The V2Pro adds Gbit transceivers and hard processors I think that is a big difference. SteveArticle: 49643
I always assume that Xilinx want to sell silicon. That's why they provide the free tools. Anyone wanting state-of-the-art has to pay through the nose for it. That makes them the market leaders. After some time the tools may be made freely available to use mortals to sure-up the market. IMHO Dave <hamish@cloud.net.au> wrote in message news:3dd5ee42$0$12778$afc38c87@news.optusnet.com.au... > Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote: > > Has Xilinx said anything about future versions of WebPack being able > > to support the 2VP4? It seems a shame that it doesn't support at > > least one part that actually contains a PowerPC processor. The number > > Why wouldn't you buy the tools if using such a high-end part? > > Hamish > -- > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 49644
Xie, In 3.1i, there are macro libraries that are obseleted in later software. Starting from 4.1i, ECS no longer has macro libraries. Instead, it has macro symbols that's composed of primitives. Therefore, what you should try to do is perform post translate (NGDBUILD) simulation. Or run NGD2VHDL or NGD2VERILOG and run simulation on the returned source code. -Wei Xie Jubo wrote: > Hi > I create a schmatic symbol in ECS in foundation 3.1i, synthesize is passed, but when i simulate it in MODELSIM an error occured that is it can not find vertex_macro library, but when i map the library in FPGA library manager, i cannot find this library in it, there are only simprim and unisim and logibox library, if the file of fpgavender_xilinx.tcl is outdated? > > thanks > > xieArticle: 49645
nospam wrote: > > already5chosen@yahoo.com (Michael S) wrote: > > >hmurray@suespammers.org (Hal Murray) wrote in message news:<utd7cdm3r2gsac@corp.supernews.com>... > >> >I am not familiar with the techXclusive, can you provide a URL? > >> > >> http://support.xilinx.com/support/techxclusives/metas-techX32.htm > > > >Good article. Unfortunately, it doesn't mention the temperature > >conditions for the mesurements. > > > >Recently we suffered a problem which I attribute to metastability. Our > >design fed Intel 386EX processor with asynchronous READY# signal. > >Simetimes it caused the hang up. The processor's RD# signal was > >indicating that READY# is accepted while correspondent CS# signal > >remained asserted, indicating that READY# was missed. Looks like > >classic metastability problem, doesn't it ?! > > I would attribute it to a duff design - the 386EX datasheets specify a > setup and hold time for the READY# input. The datasheets do not specify > what happens if READY# is not stable during that period. You experience > shows the processor can get screwed up pretty badly - but it is still your > fault. > > The 'problem' inside the 386 is almost certainly a race and not > metastability. > > I do wish chip manufacturers would be a bit more specific about which > violation of timing specifications can really screw up their parts. I had a similar problem with a TI DSP once and tried to get them to tell me which edge of the clock the signal was sampled. Then I could make a resonable attempt to synchronize with the input sampling. But they would not or could not understand what I wanted to do and just kept telling me that it was an "asynchronous" signal and there was *no* setup or hold to the clock. We all know the part is synchronous internally, but I just could not get through to anyone that understood what I wanted. So I would not expect much understanding from a chip vendor on an issue like this. They tend to see their parts through blinders. -- 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: 49646
>> Nor is the V2Pro. It's a lateral move from the V2,
>> kind of like the move from Virtex to Virtex-E
>
>I have to disagree the Virtex E just a different mix of the same stuff.
If I understand correctly, the Virtex-E (and Spartan-IIE) are process
shrinks, without an architecture redesign. So the voltages are lower
(damn) and the speeds are faster (hooray!), but this is not what
one would call qualitative change.
>The V2Pro adds Gbit transceivers and hard processors I think that is a big
>difference.
Sure, it can be a big difference for real-life use,
but it's not a change in the FPGA fabric itself.
Just in the "peripherals". So calling it a new "generation"
of FPGA sounds like marketing fluff. 'Specially since
the FPGA cells that the PPC displaces are enough to make
a soft RISC core.
- Larry
Article: 49647Hal Murray wrote: > > Suppose the problem is a simple setup problem - it takes x ns to setup > FF X, and y ns for the same signal to get setup for FF Y. Anything > between x and y will cause troubles. Just adjust temperature to hit > that window. But if you are working on the late side of both X and Y you are violating the setup time of each FF! That is not the right place to be since minimum delays are not guaranteed. Any properly verified design should be working on the early side of both X and Y and will only get earlier as the temperature drops. > Similarly, if you only have one FF, and the setup time is z, then > you will get no metastability problems if you meet z, and you will get > a lot of them if you are a little under z. (I'm talking measured > setup times for this particular device/conditions, not data sheet times.) > Temperature changes on one device (cold spray) could easily change the > actual setup time for another device while the setup time it needs doesn't > change much because its temperature doesn't change much. Again, if you don't meet the data sheet times, you don't have a correctly verified design. Good synchronous design requires that you meet all setup times under worst case conditions and input hold times are best if they are zero, since that is the only hold time you can guarantee. -- 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: 49648
nospam wrote: > <snip> > The 'problem' inside the 386 is almost certainly a race and not > metastability. > > I do wish chip manufacturers would be a bit more specific about which > violation of timing specifications can really screw up their parts. This assumes they actually know this information :) -jgArticle: 49649
Michael S wrote: > > It has nothing to do with Xilinx. I just brought my case as an example > of the temperature dependency of the (supposed) metastability. Ok, I thought you were referring the problem back into the Xilinx part. > > > > In general, I would expect the effect of temperature to be small in > > relation to the exponential effect of slack time. If you see a > > metastable failure at *any* temperature, it is because not enough time > > was provided for settling. > > I never studied the theory of metastable flip-flops. But intuitively I > see metastable state as a very small local minimum on the energy > curve. At the higher temperature the thermal noise can be strong > enough to rescue the flip-flop out of this state to the stable one. > It's all my speculations, may be, I erroneously apply the lows of > microworld lows to the macroworld phenomenon ? There can be no local minimum or it is not a "meta"stable state. Then it would be a stable state in the absense of sigificant noise. An analogy is a pencil balanced on its rounded eraser end (I used to say a perfectly sharp point, but some started to argue about how sharp it could be before quantum mechanics kicked in... jeeeez!). Like a switching FF, it will take some time to go to a stable state. But it can be just close enough to the perfect balance point that it might take a while to move off center. The closer to the balance point, the longer it can take, so there is no maximum metastable time. I have tried to analyze the behaviour of such an analogy in the presence of noise, but I don't have the tools to do it rigorously. It may well be possible to shorten the metastable time with noise, but I really can't prove it one way or the other. I think the bottom line is that even if noise will help, you are not going to add noise to your digital circuits to help metastability rather than to add the delay to the FF output path. It would be a bit hard to explain to a chip user that they are *required* to provide a minimum amount of noise to make the chip work to spec!!! -- 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 FAX
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