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
"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:464b84eb$1@clear.net.nz... > > FPGAs themselves are not designed to give time-delays. > ...but they're very proficient at it when you don't want them to be! :-) Cheers, Syms.Article: 119351
Hi, my name is Pablo and I have problems with the use of semaphores in xilkernel. I have created a struct based on pthread_t types, semaphores,... That is, I create a "mypthread_T" which is based on a pthread_t and a semaphore. Each pthread_t has an associated semaphore. The situation is the following: One father thread (thread 0) freezes in a sem_wait().Then there is two another threads, one of them (thread 1) is freezen in anothrer sem_wait and the another one (thread 2) makes a sem_post to unlock the previos thread (thread 1). But sem_post unlocks the father thread (thread 0). I have verified the location of the semphores and everything is ok. The question is: Has anyone found some semaphore bugs in xilkernel?? ThanksArticle: 119352
Hi all ... I have been writing VHDL for many years now, but can't seem
to figure something out. I'm writing a component called "cell" (no it
has nothing to do with the cell processor). Since there are so many
different variations on my cell architecture I have chosen to use
generics and generate statements to create the necessary cell type
based on generic values.
Notice below that I have an input ep_in. Well, on some cells I don't
need that input because the number of eprobs is zero. However, if I
set num_eprobs to 0, ep_in becomes std_logic_vector(-1 downto 0).
Is there some way to disable the ep_in port when num_eprobs is 0? If
not, does anyone have any clever ideas on how to get around this?
Thanks,
James
entity cell is
generic (cell_type : cell_types;
num_children : integer range 1 to 6;
num_eprobs : integer range 0 to 16;
precision : integer);
port (
clk : in std_logic;
reset_l : in std_logic;
--
c_in : in std_logic_vector(num_children*precision-1 downto 0);
tp_in : in std_logic_vector(num_children*precision-1 downto 0);
ep_in : in std_logic_vector(num_eprobs*precision-1 downto 0);
--
val : out std_logic_vector(precision-1 downto 0)); -- output
end cell;
Article: 119353On May 16, 9:56 pm, jrabb...@gmail.com wrote: > Hello, > > I have recently bought a Virtex-4 LX25 evaluation board from Avnet. It > has Cypress FX2 chip for USB 2.0 communication support. The generic > USB driver provided by Cypress is of no use to me. Whenever I connect > the USB of the board with the PC, the immediate message is "Unknown > USB device". This happens because the VID and PID of the device > received at the host is 0. I have tried installing the driver with > EZUSBw2k.inf as well as CyUSB.inf but none has worked. Is there any > body out there who has used the FX2 with Cypress provide generic USB > driver? If someone has used USB with an Avnet board, that will prove > very helpful to me. Looking forward to a sound advice. Thanks. > > - Javed Rabbani Sounds similar to the issue i had with the Cypress FX2 microcontroller. On some computers it does not start-up properly, even with the proper drivers installed (it was detected as an 'uknown device', while it should have worked even without any firmware). It turned out, that it works with other PC's i've tested it with (have you checked that?). In order to put it into working order, i had to program the onboard I2C EEPROM with startup bytes (i found the EEPROM image in an archive with the FX2 starter kit documentation). I don't know if your board is fitted with an EEPROM for firmware storage or if it uses another way to boot-up (I don't have the login/pass the Avnet website asked me about:)), but you might want to check that.Article: 119354
"James" <j@j.com> wrote in message news:2007051705160950878-j@jcom...
> Notice below that I have an input ep_in. Well, on some cells I don't need
> that input because the number of eprobs is zero. However, if I set
> num_eprobs to 0, ep_in becomes std_logic_vector(-1 downto 0).
Really you should try comp.lang.vhdl, since this isn't really anything
specific to FPGA technology. :)
> Is there some way to disable the ep_in port when num_eprobs is 0? If not,
> does anyone have any clever ideas on how to get around this?
Get around what? A std_logic_vector(-1 downto 0) is perfectly OK, it just
has no elements. It's a "null range", and it's very useful in exactly this
situation.
If you dislike it, or one of your tools doesn't support it, you could write
yourself a max function and do
ep_in : in std_logic_vector(max(num_eprobs*precision-1, 0) downto 0);
But you shouldn't need to.
Cheers,
-Ben-
Article: 119355steve.lass@xilinx.com wrote: ... > > 2) Open Source your Code without managing the project > > You can release code for less important projects like Impact without > > taking care of the open source development process. > The main complaints we get on Impact have to do with people using the > many variants of Linux. Our current plan is to look into using the Linux > USB driver to address this. When using libusb, keep also in mind that libusb seems to be available on windows too. And in the same process, think about using ppdev/parport for the parallel port driver. There is also a similar access mechanism available on windows. Look on MSDN for "System-Supplied Parallel Drivers" Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 119356
jrabbani@gmail.com wrote: : Hello, : I have recently bought a Virtex-4 LX25 evaluation board from Avnet. It : has Cypress FX2 chip for USB 2.0 communication support. The generic : USB driver provided by Cypress is of no use to me. Whenever I connect : the USB of the board with the PC, the immediate message is "Unknown : USB device". This happens because the VID and PID of the device : received at the host is 0. I have tried installing the driver with If you are seeing a VID and PID of 0 this suggests a hardware problem at a lower level than drivers! - I had this when shorting the USB D- to ground (got the pinout backwards on a connector). Possibly a bad cable or damaged PCB, or perhaps the CY7C68013 isn't correctly powered or booting. If there is bad firmware in the I2C eeprom (U12) you can try breaking the SCL and SDA tracks after the pullups and before the EEPROM to make the CY7C boot into its default state. This should be a last resort as it looks like there're no jumpers so you'd have to cut the tracks... I don't know if bad firmware can lead to the chip failing badly enough that enumeration fails. hth cdsArticle: 119357
"GomoX" <gomox.ar@gmail.com> wrote in message news:1179379000.972460.323340@e65g2000hsc.googlegroups.com... > Hey everyone, > > As an assignment for a course in my CS degree, I have to build a D > latch, a D flip flop and a 1 bit register with VHDL. I have been given > the "process" versions of those and I have to rewrite them using > elementary gates and feedback connections. > > My teachers are not really profficient in the topic (sadly) Which topic? Boolean logic or VHDL? > but we are > going through hoops to get stuff working. Does 'working' mean that the simulation is correct or does it mean that actual hardware has been built and tested? The advice that you'll get kind of depends on that (more on that later). > I have read on several pages > that because of limitations in VHDL simulations, basic sequential > circuits such as the latch/ff should not be implemented with gates but > using processes instead. The limitation comes about because of the interaction of two things: 1. Simulation allows for zero propogation delays through logic 2. The logic type most commonly used (i.e. std_logic) allows signals to be 'unknown'. Neither of these two things model the real world behaviour of anything at all....and yet they are both powerful aids for designing logic properly and are 'good' things from a design perspective. Try simulating the simplest feedback element available, the oscillator. The logic to describe it is x <= not(x); If you use std_logic type for 'x' then it will get initialized to unknown at the start of the simulation. The 'not' of an unknown is also unknown so x will never change. This is a result of #2. If you try to use type boolean instead which only has TRUE and FALSE and no 'unknowns' then x will keep toggling back and forth between TRUE and FALSE but the simulation time will never advance. This is a result of #1. > > We are sure that the circuits we described using the component-based > approach in VHDL correctly mimic the hardware versions of those. > Still, behaviours are erratic and GHDL is giving away cryptic "stop- > delta" compilation errors that we can't fix. See above discussion for the likely cause of the error. > > This appears to be somewhat confirmed by the fact that this page (the > only one I've been able to find that provides a gate-based > implementation of latches and ffs) does it with some obscure library > reference that I have not available (lsi_10k) and a complicated > definitions instead of usual signaling and port mapping with and's and > not's. Nothing complicated is needed. If this is a simulation only type of assignment that you're doing then you simply need to avoid #1 and #2. To get around #1 you make sure that every logical operation has a non zero propogation delay (or at least somewhere in your feedback loop there is a non-zero delay for every possible path). To get around #2 you need to not use std_logic type, use a logic type that only has two states. If this is intended to be built into real hardware though, don't do either of those two things. Designing a feedback loop of anything without a proper storage element will always result in flaky behaviour at best. How you implement it is also be a function of which target technology you're planning on implementing it in (hence all the postings that you've seen discouraging building flops out of gates). Since you didn't mention anything about a target device I'm guessing that this might be a simulation only assignment but in case it's not I added this caution. Kevin JenningsArticle: 119358
Two Students at TU Vienna (Alexander and Peter) have designed and built a very nice board to interface an FPGA (running JOP) with the LEGO Mindstorms system. Take a look at http://www.jopdesign.com/wiki/index.php?title=Lego_PCB and also check their web site at: http://stud3.tuwien.ac.at/~e0327019/lego/ for the feature list and images. The board is a major step towards building FPGA based robots :-) The design file is placed as open-source and you're free to build your own PCB. For those of you who don't want to solder your own board (like me) we can arrange a production run of several boards with a professional company. Please reply to the list (or to me) when you are interested in such a board. The very rough estimate on the cost for the board is EUR 100,- However, that depends also on the number of boards we will produce. Cheers, MartinArticle: 119359
Hi Kevin, If you are observing non-linearity in dynamic power at speeds close to or below your max operating frequency, I would be worried. The frequency of operation given to you by the timing analyzer is quite conservative relative to what you should observe on a single device in nominal conditions. For example, in Stratix II the timing assumes the transistor junction temperature is at 85C, that the voltage at the pins of the device is 1.15V (and lower than that at the transistor), and that they device you are using is at the very edge of timing for the speed bin it is in. Unless you are using a temperature forcer, have intentionally dropped the voltage, and somehow got your hands on a chip that is right at the binning limit, you should see faster operation in the lab. How did you measure power? And how non-linear is the power you are seeing -- can you share some data? One place where power becomes non-linear at relatively low frequencies is in the I/Os. Depending on your I/O loading, the caps can be big enough that you will be switching the I/Os before you've fully charged external loads. As you increase frequency, the signal swing is reduced dropping your dynamic power. In the core of the device, you'd need to be in the Ghz range before signal swing started to limit things. When it comes to measuring power, if you are using a standard lab DC voltage supply and measuring the current out of it, you *will* see non- linear power unless you compensate the supply. Some supplies have a lead that you can connect to the board to sense the voltage as seen at the device. Without this, you will get IR drop through the cables connecting the supply to the board, and that IR drop will increase with clock frequency. The result is lower voltage at the pins of the device, which in turn reduces the device's power consumption and also will lower the maximum stable operating frequency. Regards, Paul Leventis Altera Corp.Article: 119360
On 16 May 2007 22:16:41 -0700, GomoX <gomox.ar@gmail.com> wrote: >Hey everyone, > >As an assignment for a course in my CS degree, I have to build a D >latch, a D flip flop and a 1 bit register with VHDL. I have been given >the "process" versions of those and I have to rewrite them using >elementary gates and feedback connections. > >My teachers are not really profficient in the topic (sadly) but we are >going through hoops to get stuff working. Back to basics ... so look at the source materials from when those were the basic building blocks. If you have access to a university library (or even a decently stocked engineer's bookshelf) you could do a lot worse than looking at the original Texas Instruments TTL Data Book. Or maybe you can find the 7474 or 74LS74 datasheets online? Google is your friend... http://www.datasheetcatalog.com/datasheets_pdf/7/4/L/S/74LS74.shtml and look at the Motorola one for example - BrianArticle: 119361
There is an extremely narrow window of time where metastability occurs in a flip-flop, and the window in which prolonged metastability occurs (something close to the clock period, for example) is infintessimally small. The chances of having a large number of FFs in a metastable state for any appreciable time is essentially nil. As for "self-reinforcing from die heating", if the die is at <=85C, you are OK -- it should operate beyond the spec'ed speed. If it heats beyond 85C, it may not. It is much more likely that the FF simply registers an incorrect value of the signal (it hasn't settled to the final value), which depending on the design will result in different toggle rates for downstream nodes. Regards, Paul Leventis Altera Corp.Article: 119362
In news:hWW2i.1605$4Y.801@newssvr19.news.prodigy.net timestamped Thu, 17 May 2007 07:22:50 -0400, "KJ" <kkjennings@sbcglobal.net> posted: "[..] [..] 1. Simulation allows for zero propogation delays through logic 2. The logic type most commonly used (i.e. std_logic) allows signals to be 'unknown'. Neither of these two things model the real world behaviour of anything at all....and yet they are both powerful aids for designing logic properly and are 'good' things from a design perspective. [..]" Hi, How can zero delays or std_logic be useful? Regards, Colin Paul GlosterArticle: 119363
Peter, I know you folks at Xilinx like to claim that you've permanently solved all the world's metastability problems, our xilinx fae tells us the same things.... And maybe you're right for telecom applications and whatnot. But I hope you don't support many Hi-rel applications because I promise you, no defense or aerospace company is going to happy being told they don't need to double register asynchronous signals. Our design guidelines here at unstated defense company (sorry, i dont disclose that on the net) are VERY strict about double registering ALL asynchronous signals, no questions asked. 2 D-Q crossings and nothing else. Right or wrong, I haven't been in the business long enough to know for sure, we view metastability as a statistical thing...and like most naturally occurring statistics, zero probability tends to never exist, very very very small near zero probabilities exist. At anyrate... yes, I'm well aware of Xilinx's current stand on the metastability problem. But you yourself just said that the problem exists for "a few ns" statistically exceeding 3ns once in a universe. So lets say 2 ns is something we should design for then.... 2ns = 500MHz.... What's Xilinx's Fmax these days??? Even if its not a problem now, it's soon to become a problem again unless you're going to tell me you're done increasing your operating frequencies. anywho... our view and i believe the view of most of the defense/ aerospace world is that something as simple as 2 registers is not worth ANY impact on system reliability. On May 16, 5:42 pm, Peter Alfke <p...@xilinx.com> wrote: > Maybe this is homework, or it is an interview question, but I took it > as a challenge. > Being a minimalist, and understanding metastability fairly well, I > came up with the following solution: > > Only one 4-input LUT plus a flip-flop clocked by the slow clock. > LUT inputs are: INput pulse, slow CLK signal, its own output O, the > flip-flop output Q > ( set O if Qbar AND INpulse, reset O if Q AND CLKbar, otherwise keep > O. O drives flip-flop D) > > Ah, but how about metastability? > If IN and CLK both go High within a certain bulls-eye that is <1 > femtosecond wide, then Q might be undefined for a few ns after the > rising clock edge. Statistically, the "few ns" will not exceed 3 ns > during the lifetime of the universe. The, hopefully synchronous, slow > clock domain should be able to cope with that. Otherwise concatanate > another flip-flop. > > Well, I do not know why anybody wants such a circuit, but it did > exercise the grey cells... > Peter Alfke > > On May 16, 7:09 am, Paul <pauljbenn...@gmail.com> wrote: > > > > > General rule of thumb is that you want 2 registers to cross between > > clock domains, follow that rule to deal with any metastability > > issues. Now you just have the problem that your first clock domain is > > faster and you might not catch it with the slower domain. > > > Personally, my approach here would be to "hold" the signal in your > > CLK_FAST with an enabled register until you receive some sort of feed > > back that you've grabbed it in CLK_SLOW, bearing in mind that those > > feedback / feedforward signals should all be double registered to > > prevent metastability. Also keep in mind that an enabled register > > does NOT count as one of your two "synchronization" registers, because > > an enabled register is actually implemented as a register with a mux > > in front of it - only direct D-to-Q connections with NO combinational > > logic count for clock domain crossing issues. Now, depending upon the > > timing of it all, this could end you up with more than 1 clock pulse > > width. Assuming that you know your input pulses are spaced far enough > > apart that you KNOW it's not ACTUALLY multiple pulses, then a simple > > edge detect will fix this problem for ya. > > > The ideal behind the metastability stuff is that if you clock a signal > > exactly at the transisition the output of the flop has some > > probability of floating somewhere between 0 and 1 for some amount of > > time. Adding any combinatorial logic extends that amount of time. > > The idea of having 2 registers is that you reduce your probability of > > a metastable event because even if you hit that .01% chance of it > > remaining metastable for long enough to create a problem at the first > > register, you got another .01% on your side at the second register. > > (Note: .01% is much higher than it really is.. but remember, if you're > > clocking signals in the MHz range, those tiny probabilities add up > > REAL quick!) > > > On May 16, 1:35 am, himassk <hima...@gmail.com> wrote: > > > > Hi, > > > > Please suggest me how to transfer a single clockwide pulse from high > > > frequency clock domain and create a single clockwide pulse in a slow > > > clock domain? > > > What are different methods available? > > > > Thanks in advance. > > > > Regards, > > > Himassk.- Hide quoted text - > > - Show quoted text -Article: 119364
On May 16, 6:50 pm, <steve.l...@xilinx.com> wrote: > > The main complaints we get on Impact have to do with people using the > many variants of Linux. Our current plan is to look into using the Linux > USB driver to address this. > Please, please, use libusb One programming model that works on BOTH linux *and* windows, using a driver that is open and fixable by the community if problems are discovered. Unlike that proprietary nightmare of a cross platform idea.Article: 119365
On May 16, 11:20 pm, mohan <kulka...@math.net> wrote: > i am using altera cpld.using quartus 2 tool to programme it through > byte blaster cable. > I have installed drivers for the cable.made connections intact. > i am getting error as "Unable to scan device." > My assusmption was may be because of loose contacts this error was > coming.but connections are intact.supply are proper,still i cann't > programme cpld. > is there any possibility of jtag port of cpld being damaged? > i had programmed the cpld through the same method.but today i am not > able to programme it,nor erase cpld.what the functionality cpld do > have stored in it,still there. Of course it's possible. It's not at all common with some types of devices to blow some of their I/O's while others and the core remain apparently functional. But I doubt it's the most probable problem. Much more likely something is strange with your board, programmer connection, or computer configuration. The logic thing to do in an industry environment would be to try another board/device with the same programmer setup. I take it you don't have another available?Article: 119366
On May 17, 12:16 am, GomoX <gomox...@gmail.com> wrote: > Hey everyone, > > As an assignment for a course in my CS degree, I have to build a D > latch, a D flip flop and a 1 bit register with VHDL. I have been given > the "process" versions of those and I have to rewrite them using > elementary gates and feedback connections. > > My teachers are not really profficient in the topic (sadly) but we are > going through hoops to get stuff working. I have read on several pages > that because of limitations in VHDL simulations, basic sequential > circuits such as the latch/ff should not be implemented with gates but > using processes instead. Yes, you really don't want to do that. Looping back a combinatorial output makes a sort of infinite loop of dependencies for the simulator to try to make sense of. In the real world it works because of delay and capacitance and stuff like that, but an HDL simulator it's not designed to do physical modeling of actual devices! Instead it's designed to simulate the application-level behaviour of devices that can be reasonably represented with just a few paramaters (like propogation delay), and having just a few states, (like 1, 0, undriven, and unkown) If you want to do something like what you are talking about, try playing with software that's designed to simulate the analog behaviour of real devices, which is to say spice. Get yourself some simple logic gate circuits to put in a spice deck and play with graphing how that responds over time to "digital" inputs.Article: 119367
On May 16, 9:50 pm, Test01 <cpan...@yahoo.com> wrote: > Are you using this for a source synchronous application? Yes, however at that time I'm only looking at the serializer, let's leave deserializer for a moment. My final implementation will not use any specialized blocks (I'm about to use Spartan-3). I just want to understand why do they need this extra (in my opinion) register in the serializer block. I'm just learning from exisitng solutions :) Best Regards, PrzemyslawArticle: 119368
Why not use three registers to make the probability of failure even less? How about 4? When the metastability window is in the sub-femtosecond range, the probabilities of hitting the window get very small. The double register will reduce the probability significantly. But it's already an extremely small probability. If you *do* hit the metastability window, having timing margin to support the extra metastability delay by applying constraints will guarantee all paths get the correct value except for once every... what is it? Several billion years? If you're running at speeds such that the timing path cannot be reduced then yes - having the second register guarantees every register downstream gets the same value. Even if the metastability time is longer than the clock period, the possibility of hitting the metastability window in that second register is almost negligible. Almost. But there's always a chance. If you're running a 100 MHz design, you may be able to afford an 8ns cycle for your synchronized input from a single flop to the remaining logic. It may not be practical in that 100 MHz system to wat an extra clock cycle for every toggle of the asynchronous signal. If it's fine to delay an extra clock cycle, the reduced timing constraint burden is a good thing to have. For designs that push the devices' top speeds, the 2 ns difference may not be acceptable. But not everyone is designing at 500 MHz and can accommodate an extra clock cycle. I call this kind of decision-making "engineering." - John_H "Paul" <pauljbennett@gmail.com> wrote in message news:1179407855.921375.242960@k79g2000hse.googlegroups.com... > Peter, > > I know you folks at Xilinx like to claim that you've permanently > solved all the world's metastability problems, our xilinx fae tells us > the same things.... And maybe you're right for telecom applications > and whatnot. But I hope you don't support many Hi-rel applications > because I promise you, no defense or aerospace company is going to > happy being told they don't need to double register asynchronous > signals. Our design guidelines here at unstated defense company > (sorry, i dont disclose that on the net) are VERY strict about double > registering ALL asynchronous signals, no questions asked. 2 D-Q > crossings and nothing else. Right or wrong, I haven't been in the > business long enough to know for sure, we view metastability as a > statistical thing...and like most naturally occurring statistics, zero > probability tends to never exist, very very very small near zero > probabilities exist. > > At anyrate... yes, I'm well aware of Xilinx's current stand on the > metastability problem. But you yourself just said that the problem > exists for "a few ns" statistically exceeding 3ns once in a universe. > So lets say 2 ns is something we should design for then.... 2ns = > 500MHz.... What's Xilinx's Fmax these days??? Even if its not a > problem now, it's soon to become a problem again unless you're going > to tell me you're done increasing your operating frequencies. > > anywho... our view and i believe the view of most of the defense/ > aerospace world is that something as simple as 2 registers is not > worth ANY impact on system reliability.Article: 119369
Martin Thompson wrote: > whyraja@gmail.com writes: >> i want to impliment a 64 bit floating point matrix >>multplication of matrix size 256*256, in verilog. (snip) > For example.. > How fast do you want to do it? I believe it can be done as a systolic array. I have worked on other systolic array designs, but not this one. > Are you going to use internal or external memory to store your > matrices? (Are there devices with 12MBit of internal BRAM...?) The OP didn't say how fast it needed to be done, which is an important parameter. That mostly tells you how many operations you need to do at once, which then tells how much hardware you need. It may be that it needs more than one FPGA, which would make more memory available. Systolic arrays tend to use both internal and external memory, some values flowing through the pipeline, some stored internally in each processor node. -- glenArticle: 119370
Paul, you don't have to teach me about the dangers of metastability. I am the one who has performed lots of quantitative measurements. But I am also fighting any un-qualified paranoia. In this particular design I pointed out that the effect of metastability is an uncontrollable statistical delay on the output of the flip-flop that, per description, is clocked by the "slow clock". I wrote that the "slow clock" domain probably has enough slack to accomodate a few ns of uncontrollable delay at the flip-flop output. "Slow clock" does not mean 500 MHz, in my book. I know what I am talking about, and I was forthcoming and explicit. This was a specific circuit, no need to bombard me with generalities. And for the record: Xilinx and I personally have NEVER EVER claimed to have solved the metastability problem. Because we all known that to be impossible. I have just, quite often, quantified the probabilities. BTW: I consider your posting ill-informed, offensive and slanderous. Peter Alfke ============== On May 17, 6:17 am, Paul <pauljbenn...@gmail.com> wrote: > Peter, > > I know you folks at Xilinx like to claim that you've permanently > solved all the world's metastability problems, our xilinx fae tells us > the same things.... And maybe you're right for telecom applications > and whatnot. But I hope you don't support many Hi-rel applications > because I promise you, no defense or aerospace company is going to > happy being told they don't need to double register asynchronous > signals. Our design guidelines here at unstated defense company > (sorry, i dont disclose that on the net) are VERY strict about double > registering ALL asynchronous signals, no questions asked. 2 D-Q > crossings and nothing else. Right or wrong, I haven't been in the > business long enough to know for sure, we view metastability as a > statistical thing...and like most naturally occurring statistics, zero > probability tends to never exist, very very very small near zero > probabilities exist. > > At anyrate... yes, I'm well aware of Xilinx's current stand on the > metastability problem. But you yourself just said that the problem > exists for "a few ns" statistically exceeding 3ns once in a universe. > So lets say 2 ns is something we should design for then.... 2ns = > 500MHz.... What's Xilinx's Fmax these days??? Even if its not a > problem now, it's soon to become a problem again unless you're going > to tell me you're done increasing your operating frequencies. > > anywho... our view and i believe the view of most of the defense/ > aerospace world is that something as simple as 2 registers is not > worth ANY impact on system reliability. > > On May 16, 5:42 pm, Peter Alfke <p...@xilinx.com> wrote: > > > Maybe this is homework, or it is an interview question, but I took it > > as a challenge. > > Being a minimalist, and understanding metastability fairly well, I > > came up with the following solution: > > > Only one 4-input LUT plus a flip-flop clocked by the slow clock. > > LUT inputs are: INput pulse, slow CLK signal, its own output O, the > > flip-flop output Q > > ( set O if Qbar AND INpulse, reset O if Q AND CLKbar, otherwise keep > > O. O drives flip-flop D) > > > Ah, but how about metastability? > > If IN and CLK both go High within a certain bulls-eye that is <1 > > femtosecond wide, then Q might be undefined for a few ns after the > > rising clock edge. Statistically, the "few ns" will not exceed 3 ns > > during the lifetime of the universe. The, hopefully synchronous, slow > > clock domain should be able to cope with that. Otherwise concatanate > > another flip-flop. > > > Well, I do not know why anybody wants such a circuit, but it did > > exercise the grey cells... > > Peter Alfke > > > On May 16, 7:09 am, Paul <pauljbenn...@gmail.com> wrote: > > > > General rule of thumb is that you want 2 registers to cross between > > > clock domains, follow that rule to deal with any metastability > > > issues. Now you just have the problem that your first clock domain is > > > faster and you might not catch it with the slower domain. > > > > Personally, my approach here would be to "hold" the signal in your > > > CLK_FAST with an enabled register until you receive some sort of feed > > > back that you've grabbed it in CLK_SLOW, bearing in mind that those > > > feedback / feedforward signals should all be double registered to > > > prevent metastability. Also keep in mind that an enabled register > > > does NOT count as one of your two "synchronization" registers, because > > > an enabled register is actually implemented as a register with a mux > > > in front of it - only direct D-to-Q connections with NO combinational > > > logic count for clock domain crossing issues. Now, depending upon the > > > timing of it all, this could end you up with more than 1 clock pulse > > > width. Assuming that you know your input pulses are spaced far enough > > > apart that you KNOW it's not ACTUALLY multiple pulses, then a simple > > > edge detect will fix this problem for ya. > > > > The ideal behind the metastability stuff is that if you clock a signal > > > exactly at the transisition the output of the flop has some > > > probability of floating somewhere between 0 and 1 for some amount of > > > time. Adding any combinatorial logic extends that amount of time. > > > The idea of having 2 registers is that you reduce your probability of > > > a metastable event because even if you hit that .01% chance of it > > > remaining metastable for long enough to create a problem at the first > > > register, you got another .01% on your side at the second register. > > > (Note: .01% is much higher than it really is.. but remember, if you're > > > clocking signals in the MHz range, those tiny probabilities add up > > > REAL quick!) > > > > On May 16, 1:35 am, himassk <hima...@gmail.com> wrote: > > > > > Hi, > > > > > Please suggest me how to transfer a single clockwide pulse from high > > > > frequency clock domain and create a single clockwide pulse in a slow > > > > clock domain? > > > > What are different methods available? > > > > > Thanks in advance. > > > > > Regards, > > > > Himassk.- Hide quoted text - > > > - Show quoted text -Article: 119371
Peter Alfke wrote: (snip) > Never thinkof the cable as a lumped capacitance. It is a transmission > line with distributed C and L plus some series resistance causing > losses , but I don't believe the losses will bother you much. In case of low frequencies and high source impedance the cable can be treated as lumped capacitance. This was always true for magnetic phonograph cartridges, designed for 47K load using 50 ohm coax cable. It is also true for analog telephones with 600 ohm source/load impedance and 100 ohm twisted pair cable. For telephone lines the capacitance would cause a decrease at higher (4kHz) audio frequencies. To correct for that in long runs series inductors (called loading coils) are placed in the line at regular intervals. The result is better response out to 4kHz, but it drops like a rock after that. They have to be removed for DSL to work. It was also true for the metalization layers of integrated circuits above about 0.8 micron feature size. Converting the tools to use a distributed capacitance model slowed down the conversion to 0.8 micron and below circuitry. The above only work where the wavelength is much longer than the cable length. -- glenArticle: 119372
Peter Alfke wrote: (snip) > If you have a fast scope, you can see the half-amplitude signal > driving the cable, and the additional half arriving back at the source > after about 10 ns. This reminds me on an undergrad physics lab on transmission lines. We had a pulse generator, series resistor and scope on one end, a variable resistor on the other end. Adjust the far end resistor to match the impedance, minimum reflected signal. The delay could be measured on the scope. If I remember it right the attenuation is measured with a variable capacitor on the far end, to measure the real and imaginary parts of the impedance. (I kept my lab books for some years, but don't have them anymore.) One cable we had, designed for delay, had a high inductance center conductor. The lengths were given so we could compute velocity and attenuation per unit length. -- glenArticle: 119373
Marwan wrote: > I will be coding in verilog. There will not by a host of functions > for me to call, so functions like eigenvalues and eigenvectors will > need to be coded explicitly. I have added comp.arch.fpga and comp.lang.verilog, where someone may have worked on similar problems. > Basically, my issue, is when I try to directly translate the TQLI.F OR > TQLI.C code to matlab, it just will not work for reason totally beyond > me... Someone else can help figure out Matlab. I will note that the hardware implementations of algorithms tend to be somewhat different from the usual software implementations, but you should understand the software first. Matlab seems to me a fine way to do that. I recommend systolic arrays for hardware matrix processing. The usual reason for wanting a hardware implementation is speed, and systolic arrays usually work pretty well for that. Also, they scale with problem size when needed. About how big are your matrices and how fast do you need the results? -- glenArticle: 119374
Ken, Seriously: any evidence of smoke or damage to the package, and it is all over. It is dead. We call it "electrical over-stress" which is a polite way of saying "you blew its brains out." Austin
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