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
>As of May 2000 you can buy an XC2S15 in quantity 1 through 24 for $ 7.10 How many would I have to buy to get it for $2? The point is that there are lots of apps, e.g. in miniaturised battery-powered products, where you want a full-CMOS device (not a typical PLD) but which can do a lot more than a 22V10 (which you *can* get in full-CMOS for $2) - for example something with 50 buried D-types. One also needs a small package, e.g. a TSOP-28. Not everybody wants do do a "256-deep, 16-wide FIFO with independent read and write clocks running >100 MHz". And if somebody does, they don't mind paying serious money for the device (just imagine the likely application...) - and I accept that is the market Xilinx likes to be in. Peter. -- Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y. Please do NOT copy usenet posts to email - it is NOT necessary.Article: 22376
Jon Elson <jmelson@artsci.wustl.edu> writes: > Christian Mautner wrote: > > > just installed FPGA express 3.4 today, and had to accept that now the > > step from XNF to EDIF has been taken. So I guess I'll have to dump my > > xnf-parsing perl scripts. > > (Moan), this is not good news at all. I don't care for the Aldec > schematic > editor, in a big way! I have Protel, and they can output XNF, EDIF, VHDL > and a host of other formats. But, the only format that I have seen work > is > XNF. The EDIF and VHDL files out of Protel are NOT acceptable to > the Xilinx tools (and probably anyone else). So, there's no way to make > the new tools accept an XNF? If not, is there an XNF to EDIF translator? > (I guess that would be XNF2EDF.EXE or something like that.) No, that's a misunderstanding. The Xilinx tools still accept XNF, but FPGA Express cannot create it anymore. So, what I am looking for, is actually an edif_to_xnf translator. But that's an idea, I'll check whether the Xilinx tools contain such a tool. chm. -- cmautner@ - Christian Mautner utanet.at - Vienna/Austria/EuropeArticle: 22377
OneStone wrote: > > 1. You list Binary Semaphore and the even less known term mutex yet omit > the simplest term which is a flag or flag bit. Mutex is an "even less known term" than binary semaphore ? You must move in very different circles than I. The pthreads standard (for which there are at least three popular book titles) mentions little else in the way of mutual exclusion mechanisms, besides mutexes; besides, what could be a better name for a mutual exclusion mechanism than mutex ? RennieArticle: 22378
Ray Andraka wrote: > > regarding the discovery of the LFSR: > > Consider the structure of an LFSR: it is a shift register, whose input is a modulo > sum of selected taps. The subsequent bits are just time shifted copies of the input > bit. Thus after N clocks you know exactly the current state of the LFSR assuming > the output comes from the shift register input (if it comes from a different tap it > is just time shifted, so your state might be time shifted...not a big deal). If you > know the structure of the LFSR, then you just back it up (on paper) to get the > initial value (this works because you know the modulo sum and all but one of the > inputs to that sum. Since you also know the structure, it is just a matter of > solving for the unknown bit. Once that is found then you know the state at time > N-1, and you repeat that until you get back to the initial state. > > If you don't know the structure, then you run N clocks to get to a known state. > From there each additional clock provides you with the sum from the known state. > After N clocks you have N simultaneous equations from which it is easy to solve for > the N coefficients (which are 0 or 1). So that is how the LFSR is broken. > > Encryption adds permutations and "S boxes" to further obfuscate the stream. In DES, > the S boxes are 6 input combinatorial functions that select 6 bits each and through > a ROM replace one bit value. There is an S box for each bit, so in addition to the > LFSR, you get a data dependent permutation of the data stream. I figured it would be this for the case of a LFSR with the structure you describe (Fibonacci implementation). However there is an alternate form where the taps are inputs to the stages rather than outputs (Galois implementation). The output is feed back to the taps which are XORed with the output of the preceding stage to drive the FF D input. I am sure that this is also analyzable with a little more effort. I would think that you would half to solve the state and the taps at the same time with this configuration. I guess it just becomes a tradeoff between how much work it is for someone to break and copy the protection scheme vs. the cost of developing and implementing the protection scheme... just like cryptography. But I am pretty sure that an affordable solution exists that will protect designs short of state secrets. I expect that I will be looking into this over the next few weeks. I guess one place to start is to see what is being done in the dongles. I used to know how to break them back when they were simple counters or memories. But now they seem to have gone to architectures like we are discussing. Anyone know what algorithms they use? -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 22379
David Kessner wrote: > > Rickman wrote: > > Can you define, or better yet give an example of a "cryptographically > > strong LFSR"? I do believe it when people have stated that if you know > > So how do you design a LFSR that can not be easily analyzed? > > I posted a message describing some better LFSRs, but in my news server > mess (I switched ISP's, and had to use Deja between) I think it got > lost... Can you post that message again? I was not aware that among the maximal length LFSRs there would be any difference in "strength". > The book "Applied Crypto, 2nd edition" by Bruce Schneier shows several > PRBS generators based on LFSR's that are much better. The book also > nicely describes several that are not at all secure. > > One type that is reasonably secure is called a "Bilateral Stop-and-Go > Generator". This generator uses two LFSRs of the same length. The > output is the XOR of each LFSR outputs. If the output of LFSR #1 > at T-1 is 0 and the output at time T-2 is 1 then LFSR #2 does not > clock at time T. Conversely, if the output of LFSR #2 at time T-1 > is 0 and 1 at T-2 then LFSR #1 doesn't clock at time T. > > This is just one example, the book describes several that would > be suitable. > Check out the Xilinx web site and search for JBits. While I wouldn't > call it easy to use, it does allow someone to analyze and FPGA and > essentially extract a netlist that LUT contents. After that, the rest > is just an excersize for the reader... :( If this is true, what is the reason for keeping the configuration bitstream format secret anymore? It originally was because of security for customer's designs. Now it is said to be about support for what they build and document. But if JBits brings that to light, will they have to support it as well? Surely it is not all that simple to reverse engineer the bitstream with JBITs? > > If you have > > to use Jbits to twiddle a bit then you load it into an FPGA and see what > > you just changed, then I don't consider this to be an easy way to > > reverse engineer a Xilinx configuration bitstream. > > With Jbits you can do rather high level things in a very predictable > way. It isn't just flipping bits and seeing what happens. You can > reroute traces, change LUT's, etc. without having to resort to trial > and error. > > > Others have indicated that the LFSR is less robust and I feel that the > > Xilinx design and the CPLD (or micro in my case) are more robust than my > > requirements. So depending on just how hard it is to attack the LFSR > > initial state, we may need a more robust algorithm. > > But a more robust algorithm isn't going to help as long as we can > reverse engineer CPLD's and Jbits exists. Yes, if this is true, then there is nearly no hope for security unless you just plain put a critical part of the design into a CPLD or microP. > The point is that the oscillators will tend to lock to other things > happening in the FPGA. The original posted suggested that a single > inverting feedback oscillator be used in conjunction with a more stable > crystal oscillator. The crystal clock is ran to the clock input on a > flip flop and the D input is fed from this inverting feedback clock. > In the most simplistic sense, this oscillator will tend to lock to > a harmonic of the crystal clock-- causing the flip flop to capture > more 0's (or 1's) than the other. This is hardly random and would > reduce the effective "key size" (since we would know that 80% of the > key bits are 0). That is true to some extent. But this problem is not the same as cracking a cypher. In this case having a bias for the random key would not be a big deal. It is still random enough that it prevents attacks on the key. Although we use the term random, it does not need to be "random" in the mathematical sense. It only needs to be unpredictable enough that it won't be the same very often. It could be the same number every other time as long as you are not suseptable to the reset attack where you would just reconfigure the device if it does not come up with the same key. The point here is that it reduces the amount of data that can be gleaned about the CPLD by not feeding the bitstream continously. Then as long as it will not keep repeating a small subset of possible keys, the attacker can not capture all of the used keys. So if you end up only using 2^24 keys instead of 2^32 keys, it is not a problem. > How reproducible the results are is really something that only > experimentation can provide. It wouldn't surprise me at all if it > was very repeatable given the same temp and voltage. I'm fairly > sure that if you let the board warm up then reset it 10 times in > a row you would probably get at least 2 or 3 "random number matches". Yes, this is true. I will be looking into this at a point in the future. Another way to do it is to put the random number generator in the CPLD and let a three way transaction take place. Random Number is sent to FPGA, E(RN) is sent back to CPLD, E(E(RN) is returned to FPGA for verification. If a microP is used in place of the CPLD, it may provide a way to generate true random numbers via an ADC or other method. > > I would be willing to bet that a form of stimulus, response approach > > would be the most resistant to attack. > > Not as long as Jbits is around. That alone would kill it. This type > of attack is independent of the algorithm used. Just find the signal > that disables some important internal state machine and force that > signal inactive. Since you can read the netlist from the FPGA this is > a relatively simple thing to do. > > Then there is the question of being able to "disable" the security > bit in Flash CPLD's and uC's. I think that this is difficult, but > possible. It may be possible, but again we are not trying to protect state secrets. Personally, I feel that any method that requires you to take the "lid" off of a chip is not likely to be used to reverse engineer a design. Tapping a bitstream and using a computer program to decode a LFSR or configuration bitstream is very much a viable, low dollar attack. So if JBits can really be used to find and reverse engineer the circuit in the FPGA, (or really just disable it!) then none of these methods will work. > Given the above two attacks, a reasonably design LFSR is just as secure > as a stimulus/response type of algorithm and a lot easier and smaller > to implement. I'm not saying that an LFSR approach is totally secure, > just that it is no less secure than a stimulus/response method given > these likely methods of attack. Except that a constantly running LFSR can be reverse engineered very easily, no need for JBits or any other software. This is likely true for any circuit short of DES that runs full time spitting out its data. Even cyphers are used according to how they want to protect them. The most important cyphers are used for only the highest level messages so that less data is available to attack. The same would be true here. I would like to hear from Peter Alfke about the capabilities of JBits. Peter, is it true that JBits allows a design to be reverse engineered and even modified relatively easily? -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 22380
Christian Mautner wrote: > > Rickman <spamgoeshere4@yahoo.com> writes: > > > I think what is being said is that you must have mistakenly selected the > > USERCLK for the Startupclk in the GUI. There in normally not a strong > > reason for changing the default from CCLK to USERCLK. If you do have a > > reason for this change, then you need to provide a USERCLK to the > > StartUp component in your design. Otherwise just change it back to CCLK! > > > > I'm using the USERCLK (being the system clock of the fully synchronous > design) always at the startup clock. I believe that, if CCLK is used, > timing constraints might be violated (since CCLK is asynchronous to > the system clock) at startup. Is this more carful than necessary? > > chm. This is exactly the reason that you would want to use a USERCLK for startup. But it may or may not be necessary depending on how your circuit works. If you have a reset that is external to the FPGA, then you can hold the entire circuit in reset when it is done configuring. Then when the reset is released, the FPGA will start correctly. If you don't have an external reset, using a USERCLK for startup would be a good idea. But then you have to tell the design software that this is what you are doing by adding the startup block to your design and showing where the USERCLK is coming from. Just selecting the bit in the configuration stream is not enough. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 22381
Paul Bunyk wrote: > > Hello everyone! Thank you all for your replies! > > You all basically suggest the simplest experiments ann of which have > already been done. What I needed is an idea for "something" which requires > couple thousand gates (sponsor's limitation on the simplicity of the demo). > By the way, another group here (well, two more people :) ) is > designing like 16-bit oversampling ADC chips with digital filters (run > now at about 15 GHz internal frequency) and DACs (including a real > cool device - voltage amplifier with exactly INTEGER gain - it's a > quantum technology, many weird things are possible). But for > prolitical reasons our demo should not resemble "just" a digital > filter, it should be programmable... > > Any further suggestions? :) If you are interesed in FPGAs with simple structures, then you might want to look at the Atmel 6000 family. The repeated logic element is a single FF with three gates and a tristate buffer. Of course there are muxes used to select the paths and SRAM to control the muxes. But this is a rather simple logic block compared to the other vendors. You might even get them to work with you and provide bitstream info so that you can use their software. This structure is very useful for systolic processing since it uses direct connects between cell neighbors. Or based on the signal processing devices being built by others in your company, you might want to build an NCO and/or a Digital Down Converter. If your circuits really run at multiple GHz speeds, then you could do the accumulators and filters in bit serial fashion to keep the circuit size down to 1 or 2 K gates. You might even be able to generate the sine and cosine as a calculation using the CORDIC (sp?) algorithm. Ray Andraka knows a lot about this. I believe he has some papers posted on his web site about it. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 22382
I believe if you work thru the boolean equations, you'll find the Fibonnaci and Galois forms are mathematically equivalent - they can be made to generate the same sequence when observed at a particular point on the shift register. That means of course, you can use the form most convenient for the analysis or the particular circuit design. I'm not sure off hand what happens to the analysis if you start modifying the feedback by XORing with parallel input data, like you would do for a CRC. Rickman wrote: > I figured it would be this for the case of a LFSR with the structure you > describe (Fibonacci implementation). However there is an alternate form > where the taps are inputs to the stages rather than outputs (Galois > implementation). The output is feed back to the taps which are XORed > with the output of the preceding stage to drive the FF D input. I am > sure that this is also analyzable with a little more effort. I would > think that you would half to solve the state and the taps at the same > time with this configuration. > -- > > Rick Collins > > rick.collins@XYarius.com > > remove the XY to email me. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.com -- P.S. Please note the new email address and website url -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 or http://www.fpga-guru.comArticle: 22383
Hal Murray wrote: > > > What the industry needs for FPGAs to take off is some sort of DES like > > encription which can be OPTIONALLY used on the bit stream. > > Do you have any data to verify that "take off" claim? Do you really > think the volume of parts shipped would double if they had a solid > anti-theft story? Not double, but it would have an impact. I wound up doing several small ASIC designs that should (by cost + EWO) be put into FPGAs. They are not because FPGAs are just too easy to copy. I've heard of several cases over the last few years (some on this group) where people have lost their shirts to people who create knock offs of their boards. People do ASICs mainly for high volume, or high performance. FPGAs are catching up fast in both of these areas. Crypto is a very small thing that an FGPA vendor could do that would give them an edge on their (and our) competition. > I'll toss in my two cents worth. All of the FPGAs I've worked on > didn't have any security issues. They were used in complicated > systems that were low volume. (If you could make them significiantly > cheaper we would buy them from you rather than build them ourselves.) Where it may hit you is on an interface board. I've seen several designs that were an FGPA, some memory, and some standard I/O interfaces and nothing else. If you put a design like this design out there, and it does something useful, (worth coping) be assured that there will be a knock off of it appearing on the market quickly. If it shows up on the Asian market, you may not even find out about it until one of your customers comes back to you with a problem. -- NAME: David W. Bishop INTERNET: dbishop@vhdl.org ( \ ) US MAIL: Hilton NY 14468-9101 A Long time ago, \__\/ PHYSICAL: 43:17:17N 77:47:37W 281' In a Galaxy far, far away... | | For Supernova info: http://www.ggw.org/asras/snimages | | For VHDL/Synthesis info: http://www.vhdl.org/siwg _/___\_ All standard disclaimers apply. [_______]Article: 22384
Matt Gavin wrote: > > FPGA gurus, > > I am programming a Virtex XC400, after synthesizing > with Synplify. Synplify claims to be finding my three clocks > requiring global buffers (two input clocks, one internal.) > I am hardwiring the locations of the two input clocks to pins > 89 and 92 (which of course are global buffer pins). > > I am having problems putting a normal (non-clock) input > on one of the global buffer input pins that I am not using > for a global buffer (pin 213). The error message from the mapper > follows. > > Running directed packing... > ERROR:xvkpu:19 - The symbol XTAL1200K.PAD failed to join a regular > I/O > component as required. The symbol has a constraint (LOC=P213) > that specifies > an illegal physical site for the component. Please correct the > constraint > value. > Problem encountered during the packing phase. I'm pretty sure that I've hit this one before with Synplicity. Put a "syn_noclockbuf" attribute on the pins that you are tying to IBUFGs in your design and it should work. In Synplicity, if you put a clock buffer on a pin, it will happily place another one right after it. I've filed this one as a bug. > 1. Shouldn't I be able to use global buffer pins for inputs > that do NOT require the global buffer? Recall that synplify > is instantiating the buffers for me. Yup, but it looks to me like the router is trying to use one of the IBUFGs as a BUFG, then is sees a pin already connected to it, and gets confused. It doesn't take much to blow the mind of Design Mangler 2.1i. > 2. Also, is there a way for me to find out which of the four buffers > are being used for the internal nets requiring clock buffers? > I can't find it in the logs. I found the problem by parsing the net list. You can also use the Synplicity RTL view window if you have that feature. -- NAME: David W. Bishop INTERNET: dbishop@vhdl.org ( \ ) US MAIL: Hilton NY 14468-9101 A Long time ago, \__\/ PHYSICAL: 43:17:17N 77:47:37W 281' In a Galaxy far, far away... | | For Supernova info: http://www.ggw.org/asras/snimages | | For VHDL/Synthesis info: http://www.vhdl.org/siwg _/___\_ All standard disclaimers apply. [_______]Article: 22385
Ray Andraka wrote: > > I believe if you work thru the boolean equations, you'll find the Fibonnaci and Galois > forms are mathematically equivalent - they can be made to generate the same sequence when > observed at a particular point on the shift register. That means of course, you can use > the form most convenient for the analysis or the particular circuit design. I'm not sure > off hand what happens to the analysis if you start modifying the feedback by XORing with > parallel input data, like you would do for a CRC. Actually, it did not occur to me that you really don't care about how the machine is implemented, you only care about the sequence. The two forms are exactly equivalent according to the reference I found. They produce the same output sequence, although the initial state of the FFs will be different for that sequence. But if you are doing a copy, you really don't care if you are building one form with it's initial state and the original was the other form with it's initial state. As long as they both produce the same output vector, you are in business. So it does not matter how you analyze it, you just need to produce the vector and 2N bits is enough data to reproduce a simple LFSR. This sounds like a good excuse for me to read a few books on cryptography. I have been waiting for an excuse to do this for a long time. I know that DES is not a simple algorithm to implement in hardware. But by doing things in a bit serial manner and using CLB RAMs as much as possible, do you have any idea how small it can be made? Even if only 1 K bits per second can be produced, this would be enough to use in an application like this. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 22386
> What is the recommended way to start up the FPGA after configuration > to a known state? My flops are currently synchronous reset only, so I > wasn't using GSR. I thought maybe I could use the DONE line connected > to an I/O? Or is it just better to make all my flops asynchronous > reset so I can use GSR? BTW, my flops as sync reset because that is > how they are implemented on the asic I am eventually going to target. There was a lot of discussion on this topic a few months ago. You might find something interesting in deja-news. I don't remember what the Subject was. I think the answer depends upon whether you are trying to target for the ASIC and have plenty of room in your FPGA or if you are working on a design that pushes the limits (both space or speed) of the FPGA. Here is what I remember from the previous discussion. The Xilinx CLBs include a free asynchronous reset connected to GSR. GSR is so slow that you can't use it cleanly - there is no way to meet setup times. If your design calls for a synchronous reset, that will turn into extra logic. As a first cut, it needs one of the CLB/LUT terms. If your design has them to spare it might not cost you much. If your design is heavily optomized it might add another layer of logic. I think consensus was that the best approach was to use GSR to reset state machines and then make sure that the first transition out of reset was clean. That probably involves another FF local to each state machine to delay the first state transition a few cycles. -- These are my opinions, not necessarily my employers.Article: 22387
Christian Mautner wrote: > No, that's a misunderstanding. The Xilinx tools still accept XNF, but > FPGA Express cannot create it anymore. So, what I am looking for, is > actually an edif_to_xnf translator. But that's an idea, I'll check > whether the Xilinx tools contain such a tool. I just got Foundation Base Express, and am getting it figured out. I DID get it to take in a top-level schematic in XNF, but have had no luck in bringing in 2nd level schematics, which were really my own macros called by symbols on the main page. It keeps complaining about those macro definition XNF's, and I have tried a WHOLE lot of things with no luck. I'm just about to give up, and enter the whole thing over in Aldec, entirely within foundation. I'm pretty sure there is a way to do edif -> xnf, darn sure I came across that somewhere. Might be part of the Synopsys software, and not explicitly part of express, but the .exe included for completeness. Thanks for the info, JonArticle: 22388
I probably just move in much older circles than you, before the computer world went insane with jargon. Mutual exclusion mechanism smacks of the same sort of mentality that turned housewifes into domestic engineers, and directory enquiries operators into information consultants. Since pthreads are a POSIX multithreading standard I have never had cause to read about them extensively or use them in any embedded systems. And a review in Amazon showed that only the Butenhof book seemed to be really popular, the numbers sold on this subject hardly makes the book 'popular'. Perhaps reasonably popular amongst POSIX programmers, but my HC12, HC16, and even my MCORE systems aren't running POSIX, definitely none of my 8 bitters do. Al Rennie Allen wrote: > > OneStone wrote: > > > > 1. You list Binary Semaphore and the even less known term mutex yet omit > > the simplest term which is a flag or flag bit. > > Mutex is an "even less known term" than binary semaphore ? You must > move in very different circles than I. The pthreads standard (for which > there are at least three popular book titles) mentions little else in > the way of mutual exclusion mechanisms, besides mutexes; besides, what > could be a better name for a mutual exclusion mechanism than mutex ? > > RennieArticle: 22389
Jon Elson <jmelson@artsci.wustl.edu> wrote in message news:39132DDE.8A14AD1E@artsci.wustl.edu... > (Moan), this is not good news at all. I don't care for the Aldec > schematic editor, in a big way! >I have Protel, and they can output XNF, EDIF, VHDL > and a host of other formats. But, the only format that I have seen work > is XNF. The EDIF and VHDL files out of Protel are NOT acceptable to > the Xilinx tools (and probably anyone else). So, there's no way to make > the new tools accept an XNF? If not, is there an XNF to EDIF translator? > (I guess that would be XNF2EDF.EXE or something like that.) I think the original statement about FPGA Express meant that it will only output an edif file instead of xnf. But the Xilinx P&R tools (Alliance) are completely independent of the front-end design entry tools - they accept edif or xnf files and will continue to do so (or at least that's what I've heard). Mark Harvey.Article: 22390
Rickman <spamgoeshere4@yahoo.com> writes: > Christian Mautner wrote: > > > > Rickman <spamgoeshere4@yahoo.com> writes: > > > > > I think what is being said is that you must have mistakenly selected the > > > USERCLK for the Startupclk in the GUI. There in normally not a strong > > > reason for changing the default from CCLK to USERCLK. If you do have a > > > reason for this change, then you need to provide a USERCLK to the > > > StartUp component in your design. Otherwise just change it back to CCLK! > > > > > > > I'm using the USERCLK (being the system clock of the fully synchronous > > design) always at the startup clock. I believe that, if CCLK is used, > > timing constraints might be violated (since CCLK is asynchronous to > > the system clock) at startup. Is this more carful than necessary? > > > > chm. > > This is exactly the reason that you would want to use a USERCLK for > startup. But it may or may not be necessary depending on how your > circuit works. If you have a reset that is external to the FPGA, then > you can hold the entire circuit in reset when it is done configuring. > Then when the reset is released, the FPGA will start correctly. If you > don't have an external reset, using a USERCLK for startup would be a > good idea. But then you have to tell the design software that this is > what you are doing by adding the startup block to your design and > showing where the USERCLK is coming from. Just selecting the bit in the > configuration stream is not enough. > Certainly. This is where this thread started, selecting the bit, but not using the startup block. If USERCLK is selected, the startup clock input should fed by the system clock, as I said. Another point is: What timing can I expect from the GSR signal? I mean, at a clock cycle period of t, how small may t be, so that all flip flops are ready at the first clock edge after the GSR? And is this covered by any timing constraints? chm. -- cmautner@ - Christian Mautner utanet.at - Vienna/Austria/EuropeArticle: 22391
In article <2063ed28.2d0ad971@usw-ex0102- 016.remarq.com>, erica <ericaNOerSPAM@remarq.com.invalid> wrote: > I am taking a class in computer organinzation and design. We > can use XLINX or Altera. I chose to user Altera MAX PLUS II. I > need a good web source on how to create modules. Can you help > me please? > > Thanks, > > Erica > > * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * > The fastest and easiest way to search and participate in Usenet - Free! > > If you are a new user to MaxplusII then you should use the getting started guide at http://www.altera.com/html/literature/lsoft.html and for examples you can refer to http://www.altera.com/html/atlas/examples/examples .html. If you have problems using the software you can also call Altera Technical Support line. It is absolutely free and they are always willing to help. 1-800-800-EPLD. Vikram Sent via Deja.com http://www.deja.com/ Before you buy.Article: 22392
Christian Mautner wrote: > Another point is: What timing can I expect from the GSR signal? I > mean, at a clock cycle period of t, how small may t be, so that all > flip flops are ready at the first clock edge after the GSR? And is > this covered by any timing constraints? > > chm. If there is a spec on the delay time for GSR, it will be in the data book. But you will likely want to design your circuit so that it does not matter. If you have some other signal holding the important logic in the reset state, then the GSR will not matter. Typically you only need to worry about a portion of the logic in such a circuit. For example in a FSM, only the transition from the reset state needs to be held off by the synchronous signal. Also any logic in the data path will be controlled by the FSM and does not need the synchronous signal. You can look up the GSR delay time, but it will be slow compared to what you will likely need to run. So find other ways to work around it. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 22393
Rennie Allen wrote: > > OneStone wrote: > > > > 1. You list Binary Semaphore and the even less known term mutex yet omit > > the simplest term which is a flag or flag bit. > > Mutex is an "even less known term" than binary semaphore ? You must > move in very different circles than I. The pthreads standard (for which > there are at least three popular book titles) mentions little else in > the way of mutual exclusion mechanisms, besides mutexes; besides, what > could be a better name for a mutual exclusion mechanism than mutex ? > > Rennie I'm hardly a CS expert, but I know a few and I'll check with them. I've been dealing with semaphores (though I mostly call them flags) for years, but I heard of "mutex" for the first time in this thread. This post in particular disabuses me of the notion that the name is akin to "mutate". It sounds like pointless (probably academic) jargon to me. Am I benighted? Jerry -- Engineering is the art of making what you want from things you can get. -----------------------------------------------------------------------Article: 22394
On Mon, 08 May 2000 03:36:56 -0400, Jerry Avins <jya@ieee.org> wrote:
>I'm hardly a CS expert, but I know a few and I'll check with them. I've
>been dealing with semaphores (though I mostly call them flags) for
>years, but I heard of "mutex" for the first time in this thread. This
>post in particular disabuses me of the notion that the name is akin to
>"mutate". It sounds like pointless (probably academic) jargon to me. Am
>I benighted?
A semaphore maintains a count between zero and some specified maximum
value. The state of a semaphore is set to signaled when its count is
greater than zero, and nonsignaled when its count is zero. Used in
producer/consumer problems, for example. I suppose you are already
familiar with that.
A mutex is a semaphore whose state is set to signaled (unlocked) when
it is not owned by any thread, and nonsignaled (locked) when it is
owned. A mutex is a semaphore set to 1, when created. It's a special
purpose semaphore designed to control access to a critical region of
code and data. If one or more threads are waiting on a mutex, exactly
one is released when the mutex is unlocked by the holder.
It's the usage that decides which it is, I believe, and not the
details of the underlying implementation in the O/S. So from the
point of view of an operating system author, you might implement them
the same way. But they are put to different purposes.
You can usually recognize a mutex when you see something like this:
myobject.down();
// serialized access to data
// ...
myobject.up();
Operations on a mutex travel in pairs, like nuns. This the above
example, myobject is a mutex.
But if you see something like:
myobject01.down();
myobject.down();
// serialized access to data
// ...
myobject.up();
myobject02.up();
chances are that myobject01 and myobject02 are common semaphores.
Maybe that's just academic, as you suggest, but that is still my sense
of the terms.
Jon
Article: 22395Reverting to my idea of a stimulus/response approach we could modify from 1 shot as I originally intended to a continuous stream of S/R pairs. Making the assumption that we have a reasonably good RNG it might still be possible to use a simple LFSR type structure if we let it evolve with time. i.e. the XOR structure for the stimulus/response pair N is determined by the random number used in pair N-1. It appears, on the face of it, that this would be much harder to analyse. BTW: I've never looked at JBITS - what exactly does it do ?Article: 22396
Hi Matt, I'm using a different front-end flow (Exemplar) but have got the same error from the Xilinx tools. It seems to me that a signal connected to a global clock pin must go through the associated buffer; have a look at the sections on clock distribution and input/output blocks in the Virtex datasheet. As a result it is possible to run out of clock buffers for internally generated clocks even though the total number of clocks in the system is less than four. The solution is to design the board (prototype board manufacturers please take note!) so that oscillators are connected to a global clock pin AND to a general-purpose input. --Phil. Matt Gavin wrote: > > FPGA gurus, > > I am programming a Virtex XC400, after synthesizing > with Synplify. Synplify claims to be finding my three clocks > requiring global buffers (two input clocks, one internal.) > I am hardwiring the locations of the two input clocks to pins > 89 and 92 (which of course are global buffer pins). > > I am having problems putting a normal (non-clock) input > on one of the global buffer input pins that I am not using > for a global buffer (pin 213). The error message from the mapper > follows. > > Running directed packing... > ERROR:xvkpu:19 - The symbol XTAL1200K.PAD failed to join a regular > I/O > component as required. The symbol has a constraint (LOC=P213) > that specifies > an illegal physical site for the component. Please correct the > constraint > value. > Problem encountered during the packing phase. > > 1. Shouldn't I be able to use global buffer pins for inputs > that do NOT require the global buffer? Recall that synplify > is instantiating the buffers for me. > 2. Also, is there a way for me to find out which of the four buffers > are being used for the internal nets requiring clock buffers? > I can't find it in the logs. > > Thanks, > > MattArticle: 22397
David Bishop wrote: > I'm pretty sure that I've hit this one before with Synplicity. Put > a "syn_noclockbuf" attribute on the pins that you are tying to IBUFGs > in your design and it should work. > > In Synplicity, if you put a clock buffer on a pin, it will happily > place another one right after it. I've filed this one as a bug. > > > 1. Shouldn't I be able to use global buffer pins for inputs > > that do NOT require the global buffer? Recall that synplify > > is instantiating the buffers for me. > > Yup, but it looks to me like the router is trying to use one of the > IBUFGs as a BUFG, then is sees a pin already connected to it, and gets > confused. It doesn't take much to blow the mind of Design Mangler 2.1i. > > > 2. Also, is there a way for me to find out which of the four buffers > > are being used for the internal nets requiring clock buffers? > > I can't find it in the logs. > > I found the problem by parsing the net list. You can also use the > Synplicity RTL view window if you have that feature. > > -- > NAME: David W. Bishop INTERNET: dbishop@vhdl.org ( \ ) > US MAIL: Hilton NY 14468-9101 A Long time ago, \__\/ > PHYSICAL: 43:17:17N 77:47:37W 281' In a Galaxy far, far away... | | > For Supernova info: http://www.ggw.org/asras/snimages | | > For VHDL/Synthesis info: http://www.vhdl.org/siwg _/___\_ > All standard disclaimers apply. [_______] Yeah, its this sort of problem that has lead me to the decision to instantiate all the global clock buffering stuff rather than let the synth tool generate it. It does mean the design's not completely portable at the HDL level but this stuff is self contained & so can be placed in a per-technology include file. If you do instantiate anything you will need a line something like this somewhere in your file [assuming you are using Verilog]: `include "??/synplify/lib/xilinx/virtex.v" Anyway you are almost obliged to use this approach if you want to use the Virtex DLLs since the only component the Synplify can synthesise is a ``BUFDLL'' which doesn't give any access to useful things like the RESET, LOCKED, x2 etc. outputs.Article: 22398
Jerry Avins wrote: > > Rennie Allen wrote: > > > > OneStone wrote: > > > > > > 1. You list Binary Semaphore and the even less known term mutex yet omit > > > the simplest term which is a flag or flag bit. > > > > Mutex is an "even less known term" than binary semaphore ? You must > > move in very different circles than I. The pthreads standard (for which > > there are at least three popular book titles) mentions little else in > > the way of mutual exclusion mechanisms, besides mutexes; besides, what > > could be a better name for a mutual exclusion mechanism than mutex ? Hello Jerry, If you do multithreaded programming in windows, you will probably use "mutexes." They been a part of windows for quite some time. The computer word that gaulls me the most is "dereferencing" This is about as bad as flammable and inflammable. As George Carlin says "either it flamms or it doesn't!" Clay > > > > Rennie > > I'm hardly a CS expert, but I know a few and I'll check with them. I've > been dealing with semaphores (though I mostly call them flags) for > years, but I heard of "mutex" for the first time in this thread. This > post in particular disabuses me of the notion that the name is akin to > "mutate". It sounds like pointless (probably academic) jargon to me. Am > I benighted? > > Jerry > -- > Engineering is the art of making what you want from things you can get. > -----------------------------------------------------------------------Article: 22399
In article <0CF260C495FED111A6610000F866308D0E00DDBF@mail3.ntu.edu.sg>,
#YEO WEE KWONG# <P7102672H@ntu.edu.sg> writes
>Hi Evan,
>
>Thanks for your help. Below is my code for your examination. You are
>right to say that it is slightly diff. at the initial state. Thereafter,
>it should be the same after the 1st clock. I tested the code with
>Synopsys DC and FPGA express. Both give me the same warning for code
>(1). Are you suggesting that I should revert to code (2) style to pass
>the synthesis test. If that is the case, why there is a couple of
>textbook still used code (1) as a synthesizable reference code which is
>quite misleading!
>I am one of the victim which I hope not.
The "problem" is not with your code, but with Synopsys. Both styles are
acceptable, and both will produce the result you expect. Synopsys is
simply *warning* you that a signal is being read that is in not in the
sensitivity list. However, it will produce the correct results.
In this case, Synopsys is being a bit paranoid. If you look at the text
of the message for HDL-400, you'll see that it says that this "could
cause a mismatch between synthesis and simulation" - the important word
is "could"!
Synplify and Leonardo Spectrum will not give you this warning.
regards
Alan
P.S. I tried your example below in both styles and got the correct
results using FPGA Express.
>
>Look forward to your reply.
>
>architecture arcCounter of ntyCounter is
> type typCounterState is (s0, s1, s2, s3);
> signal sNextState : typCounterState;
> signal sCurrState : typCounterState;
>
>begin -- arcCounter
>
>
> lblUpdState: process(pClk) --> code (2) style
>-- lblUpdState: process --> code (1) style
> begin
>
>-- wait until rising_edge(pClk); --> code (1) style
> if rising_edge(pClk) then --> code (2) style
> if pRst_b = '0' then
> sCurrState <= s0;
> else
> sCurrState <= sNextState;
> end if;
> end if; --> code (2) style
>
> end process lblUpdState;
>
>end arcCounter;
--
Alan Fitch
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, BH24 1AW, Hampshire, UK
Tel: +44 (0)1425 471 223 Email: alan.fitch@doulos.com
Fax: +44 (0)1425 471 573
** Visit THE WINNING EDGE www.doulos.com **
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