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
Here is my simple analysis: There are two very different situations: If the transmitter clocks slower than the receiver, there is no problem on the receive end, as long as the error inside the word does not exceed half a bit time. If the transmitter clocks faster than the receiver, the receiver has to be able to resynchronize after only half a stop bit (which may be touchy). Peter Alfke ============================== glen herrmannsfeldt wrote: > > juergen Sauermann wrote: > > (snip) > > > I still do not believe, though, that inserting idle time one way or the > > other (including cutting the transmitter's stop bit) is a solution. > > Consider the following: > > > > Left side: Slow (9600 Baud) > > Right side: Fast (9700 Baud) > > > > Both sides use e.g. 8N2 for Tx and 8N1 for Rx. > > > > At some point in time, Left see's its buffer filling up and hence skips > > a few stop bits here and there (using 8N1) in order to compensate this. > > Left is now faster that Right, despite of the clock rates. > > > > As a consequence, Right sees its buffer filling up and skips stop bits > > (using 8N1) as well. > > > > This continues until both sides transmit with 8N1 all the time; at this > > time Left will loose data. > > As far as I know, asynchronous transmission was intended to be between > two devices, such as a terminal and a computer, though more likely two > terminals in the early days. > > The two stop bits were required by machines that mechanically decided > the bits. (The Teletype (R) ASR33, for example.) Using stop bits as > flow control seems unusual to me. > > Electronic UARTs (no comment on mechanical ones) sample the bit at the > center of each bit time. For a character with no transitions (X'00' or > X'FF') timing error can accumulate for the duration of the character. > The STOP bit is the receivers chance to adjust the timing, and start > over with the new START bit. > > With a 5% timing error, which is very large for a crystal controlled > clock, the stop bit could start 0.45 bit times early, but the receiver > will still detect it at the right time, and be ready to start the next > character. > > The timing for each character is from the leading edge of the START bit. > > This allows for difference in the bit clock rate between the transmitter > and receiver. It is unrelated to any buffering or buffer overflow > problems that may occur. > > -- glenArticle: 63576
Dear all, Is PCI the only convinient interfacing unit that talks with CPU by inserting something into a computer conviniently? What is the speed of that? Is there any faster method? Thanks a lot, -WalalaArticle: 63577
Jim, The big question is: "would anyone want to pay for a FPGA that is 1/2 the speed but 1/10 the leakage?" As for Intel, great PR, but they have absolutely no way that they have announced to reduce drain source leakage. That big PR splash was for "gate leakage" which is a small problem today. THE problem today however is drain source leakage. Austin Jim Granville wrote: > "Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message > news:bq01k6$29db$1@agate.berkeley.edu... > >>In article <CXvwb.9478$ws.845858@news02.tsnz.net>, >>Jim Granville <no.spam@designtools.co.nz> wrote: >> >>>Following the recurring thread of 5V IO, >>>the loss thereof, and 'the price of progress', here are some >>>of the newest numbers from the uC industry : >>> >>> Philips LPC2129 Spartan IIE >>>General 256KF/ARM Advanced FPGA >>> >>>Vcore 1.8V 1.8V >>>Vio <5.5V <3.6V >>>Icctyp 10uA 10mA >>>IccMAX <500uA <200mA >>> >>>Icc numbers are Static, ie represent standby power levels. >>>FPGA of similar core Vcc is chosen, and smallest IIe device is chosen >>>to avoid too much die-area skew effect. >> >>A: Even a small FPGA has so many config bits and active gates that >>static leakage becomes vastly significant, while the Phillips part has >>only 16KB of SRAM (most of the storage is flash). > > > Not sure I follow this. Are you saying only SRAM determines leakage ? > I would have expected the total CMOS P-N pairs to determine leakage, > and that should be largely die area proportional (with possible factors > of Vcc disable of whole blocks, if that is done ) > > >>B: There is a tradeoff between static leakage and performance. A >>4-stage CPU pipeline with a max frequency of 60 MHz is incredibly >>biased towards low power & very low leakage, not high performance. >>Heck, the LEON sparc core in the .25 micron FPGAs will run at ~30+ >>MHz, and thats a fully synthesized, no optimization at all design! > > > I think the 60MHz is dictated primarily by FLASH access, and that > speed, inclusive of flash, is at the 'high performance' end for uC. > > >>C: Biasing towards lower leakage also allows higher Vio, as now you >>have thicker oxide layers. > > > To say it is a trade-off is correct. > It it becomming is more common to see variable oxide process offered > - it could well be being done now, in FPGAs to give 3.6IO on 1V cores. > > The point I am illustrating is that FPGAs have made impressive strides > in Speed, and features/dollar over the last 5 years, but that has come at > some other performance cost and compromise. > If they really want FPGAs to replace ASICs, or FPGA cores to expand > markets, that will be the next focus. > > Intel is a putting a LOT of R&D into leakage control, as they realise it is > restricting their expansion and deployment. > > Seems a natural 'next step' for (eg) Xilinx to take their 90nm Spartan-3 > devices, > and tune for leakage first, and speed second. > Same tools, very largely the same mask sets, but new customers - those who > would look at 200mA max, 10mA typ and say 'pity, could have used that..' > > -jg > > > > >Article: 63578
"Austin Lesea" wrote > Jim, > > The big question is: "would anyone want to pay for a FPGA that is 1/2 > the speed but 1/10 the leakage?" Agreed. If you can make it "a FPGA that is 1/2 speed, but 1/1000 leakage", it's a better question. This brings it into line with ASIC, the uC example quoted, and even the latest CPLDs Or, you could ask "Would you like our next generation FPGA to be 2x faster, or appx the same speed and 1/1000 of the standby current ?" The typical customer will, of course, reply "I'd like both" :) I can recall a time when FPGAs were chosen as the low static Icc prog. logic solution, and CPLDs were the power-hogs - today that situation seems to have reversed. > As for Intel, great PR, but they have absolutely no way that they have > announced to reduce drain source leakage. That big PR splash was for > "gate leakage" which is a small problem today. THE problem today > however is drain source leakage. Some of the strained silicon plots I saw looked an improvement - incremental, but a step in the right direction... It's on the radar, so improvements will come.... -jgArticle: 63579
Jim, The strained silicon makes for a better Idsat, so they can then up the Vt, to lower the leakage, or leave the Vt low, so they can get the speed they want. NO ONE has a clue how to solve the leakage issue. Not even close. Massive "head in the sand" approach in the industry just now beginning to shake folks up to where they are beginning to really look at it.... Austin Jim Granville wrote: > "Austin Lesea" wrote > >>Jim, >> >>The big question is: "would anyone want to pay for a FPGA that is 1/2 >>the speed but 1/10 the leakage?" > > > Agreed. > > If you can make it "a FPGA that is 1/2 speed, but 1/1000 leakage", it's a > better > question. > This brings it into line with ASIC, the uC example quoted, and even the > latest CPLDs > > Or, you could ask "Would you like our next generation FPGA to be 2x faster, > or appx the same speed and 1/1000 of the standby current ?" > > The typical customer will, of course, reply "I'd like both" :) > > I can recall a time when FPGAs were chosen as the low static Icc prog. > logic solution, and CPLDs were the power-hogs - today that situation > seems to have reversed. > > >>As for Intel, great PR, but they have absolutely no way that they have >>announced to reduce drain source leakage. That big PR splash was for >>"gate leakage" which is a small problem today. THE problem today >>however is drain source leakage. > > > Some of the strained silicon plots I saw looked an improvement > - incremental, but a step in the right direction... > > It's on the radar, so improvements will come.... > > -jg > >Article: 63580
"Austin Lesea" wrote > Jim, > > The strained silicon makes for a better Idsat, so they can then up the > Vt, to lower the leakage, or leave the Vt low, so they can get the speed > they want. > > NO ONE has a clue how to solve the leakage issue. Not even close. > Massive "head in the sand" approach in the industry just now beginning > to shake folks up to where they are beginning to really look at it.... - that's what makes it interesting to follow :) The best solutions will 'retro-fit' onto the massive FAB equipment investments, but there are also design-time solutions. Things like Power Route Switching (brute force), or variable oxide and/or variable threshold across the die ( more finese, needs process support ) etc.. In a FPGA, there could be future scope for standby style design, with a LOGIC.Core Vcc, and separate BitStreamLatches.Vcc, allowing the speed-tuned LOGIC to be powered off, but the SRAM config info could be held. Gives designers the choice of faster wakeup, from a very low power mode. Meanwhile, designers could deploy the emerging larger FLASH, low power uC devices (like my example LPC21xx ) as 'smart-loaders' - tasked to power-remove, and then re-load (compressed & secure) the FPGA info when needed. -jgArticle: 63582
In article <4SPwb.9639$ws.864267@news02.tsnz.net>, Jim Granville <no.spam@designtools.co.nz> wrote: >> A: Even a small FPGA has so many config bits and active gates that >> static leakage becomes vastly significant, while the Phillips part has >> only 16KB of SRAM (most of the storage is flash). > >Not sure I follow this. Are you saying only SRAM determines leakage ? >I would have expected the total CMOS P-N pairs to determine leakage, >and that should be largely die area proportional (with possible factors >of Vcc disable of whole blocks, if that is done ) No, I'm just saying that the number of powered gates in even a "small" FPGA is rather large, several hundred bits per CLB. There really is no silicon area on an FPGA that isn't actively powered logic these days, and densely placed actively-powered logic at that. > The point I am illustrating is that FPGAs have made impressive strides >in Speed, and features/dollar over the last 5 years, but that has come at >some other performance cost and compromise. > If they really want FPGAs to replace ASICs, or FPGA cores to expand >markets, that will be the next focus. > Intel is a putting a LOT of R&D into leakage control, as they realise it is >restricting their expansion and deployment. > > Seems a natural 'next step' for (eg) Xilinx to take their 90nm Spartan-3 >devices, >and tune for leakage first, and speed second. > Same tools, very largely the same mask sets, but new customers - those who >would look at 200mA max, 10mA typ and say 'pity, could have used that..' The low power, especially low quiescent power, really can only be done with non-SRAM config bits, as the config bits grossly dominate the static power draw. EG, a flash or antifuse technology is vastly better in the leakage department. But with SRAM-based FPGAs, leaking transistors are always going to be significant if the SIA roadmap holds, and the process games can't save a factor of 10 without DRASTICALLY slowing things down or incredibly boating the area. Likewise, FPGAs will ALWAYS be ~10x greater in the dynamic power than a comparable ASIC for "logic", as the cost of reconfigurable interconnect is simply a lot more capacitence. Again, nothing can really be done about this, it's just a Fact of Life. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 63583
> Hi, Andras, > > Thank you very much for your answer! > > I guess the first thing I need to make myself clear is that what is > the essence of this problem? Is it a ray-tracing problme or collision > detection problem? > > I need to identify the name of the problem first then I can go out and > search for similar application cases... > > Can you help me on that? > > Thanks a lot, > > -Walala Hi! I would think your problem is an intersection problem, but only you can find out the true nature of your problem. AndrasArticle: 63584
On Tue, 25 Nov 2003 06:36:03 +0200, "valentin tihomirov" <valentinNOMORESPAM@abelectron.com> wrote: >UART is used to transfer a byte in serial form bit-by-bit. I know that 10% >deriviations in frequencies of transmitter and receiver are permissible. I >was learnt that UARTs synchronyze at the falling edge (1to0) of start bit; >hence, there should allow for transfer of a stream of bytes of arbitrary >length. ITU-T Recommendation V.110 (a.k.a. I.463) explains how to do synchronous to asynchronous conversion (to get async serial signals across ISDN). This includes things like stop bit shaving. http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-V.110-200002-I Regards, Allan.Article: 63585
Greetings: Here's a response from a Xilinx fellow who responded to me by email regarding my recent query on the group about XPLA3 seeming to be de-emphasized on the Xilinx web site: --------------------------------------------------------------- Rumors of our demise are highly exaggerated! Xilinx currently has no intention of discontinuing the XPLA3 CPLD product line. This family is on the same fab module as our highly successful XC9500XL family, which is also still flying very high. These families are still gaining market share! I don't know how to post things on comp.arch, but you can quote me there if you wish. Incidentally, why isn't it interesting when our main CPLD competitor announces discontinuing about 90% of their product line? See page 29 of this: http://www.altera.com/literature/nv/03nvq3.pdf Jesse Jenkins, Xilinx CPLDs --------------------------------------------------------------- Good day! -- ____________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.govArticle: 63586
Chris Carlen <crcarle@BOGUS.sandia.gov> wrote in news:bq0tcn0217m@enews2.newsguy.com: > Greetings: > > Here's a response from a Xilinx fellow who responded to me by email > regarding my recent query on the group about XPLA3 seeming to be > de-emphasized on the Xilinx web site: > > --------------------------------------------------------------- > Rumors of our demise are highly exaggerated! > > Xilinx currently has no intention of discontinuing the XPLA3 > CPLD product line. This family is on the same fab module as > our highly successful XC9500XL family, which is also still > flying very high. These families are still gaining market share! > > I don't know how to post things on comp.arch, but you can quote > me there if you wish. > > Incidentally, why isn't it interesting when our main CPLD competitor > announces discontinuing about 90% of their product line? > See page 29 of this: > http://www.altera.com/literature/nv/03nvq3.pdf > > Jesse Jenkins, Xilinx CPLDs > --------------------------------------------------------------- > > Good day! > I just started considering the CoolRunner XPLA3. I think that Xilinx is sending this message on their web site (perhaps unintentionally). If you click on Products & Services from their home page, you are lead to believe that the only CPLDs that Xilinx is interested in selling are their CoolRunner-II parts. They list several FPGA families. The name CoolRunner -II also implies that the CoolRunner XPLA3 is the old obsolete family. All it would take is one line after the CoolRunner -II bullet to convey a different message. I would suggest that they change their web site to reflect those products that they truly consider appropriate for new design. If the XPLA3 is one of these products, then don't bury the product info. The XPLA3 has the advantage that they are 3.3V parts that are 5V tolerant. The CoolRunner - II requires a 1.8V supply which even for us DSP guys is not always available. Furthermore, there are still some reasons to have 5V tolerant I/O. Chris, maybe you can forward this to Jesse Jenkins. Just my two cents worth..... -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.comArticle: 63587
> > As far as I know, asynchronous transmission was intended to be between > > two devices, such as a terminal and a computer, though more likely two > > terminals in the early days. > > Originally developed by Emille Baudot (google) for telex. Hence Baud. Buffer overflows are irrelevant in the modern world since the terminals will be handling the data far faster than the transmission rate. All that is required is the receiving uart detect the start bit reliably. Longer stop bits help.Article: 63588
Hi all, The factory have made some mistakes when they had our V-II pcb board manufactured and assembled. and we found only the Vccint, Vccaux and Vcco4 is available for the FPGAs. To save time, we still want to do some debugging on this board before we can get our new board. Thanks god that with these 3 Vcc supplies we can download our design through JTAG, and later I found input signals of other banks without Vcco still can be used.(at least the GCLK, I've not tried other pins yet). so my question is: can anyone confirm that I really can use the input pins without Vcco. and how about its Electrical Characteristics, ?V tolerant etc.Article: 63589
In article <3FC438D4.542D2E67@acm.org>, Thad Smith wrote: > sai a wrote: > >> 2. How do you go about building [a soft-core processor]? > I suppose you either design your own with standard logic components or > license an existing a design. I believe there is one processor design > with some sort of free licensing. > > I added comp.arch.fpga to the group list. This should bring in some > more knowledgeable folk. Go read http://www.fpgacpu.org/links.html . There are a ton of free and educational soft cores from which to learn. If, after studying this material for a while, you have more questions, by all means come back to comp.arch.fpga. - LarryArticle: 63590
valentin tihomirov wrote: > > > When you say "your" UART, is this a design you did yourself in an FPGA? > Yes, you're right I have my design runs on CPLD. However, the qestion is > more in logic rather than implementation. The value 10% I have got from > www.8052.com's forum where "Software Uart" is a hot topic. Well, this is not correct. Analyze the situation yourself and see at what point the receiver will not sample the data at the correct time. You will find the allowed slip is half a bit over the whole word which is about 5% give or take. > > If so you may not have designed the logic correctly. In order for the > > receiver to synchronize to a continuous data stream, it has to sample > > the stop bit in what it thinks is the center and then *immediately* > > start looking for the next start bit. This will allow a mismatch in > > speed of almost a half bit minus whatever slack there is for the sample > > clock rate. BTW, you are sampling at at least 8x the bit rate, right? > I use 16x oversampling and check input values at middle of a bit (SampleCnt > = 7). You suggest exactly what I have done. I think receiver part will work > under any condition. That assumption is where you are wrong. There is nothing the transmitter can do to change the way it works unless you *always* transmit at a rate slower than your receiver. The transmitter can be either faster or slower than the receiver. If the transmitter is slower than the receiver, then the start bit detection will simply happen a few clocks after the end of the stop bit rather than right at the end. If the transmitter is faster than the receiver, then the start bit detection has to occur before the end of the timing of the stop bit. If the transmitter starts the start bit early you make the problem worse. If the transmitter delays the start bit, then this will prevent any issues. So you can eliminate the problem by sending two stop bits and only looking for one at the receiver, but clearly this is not how commercial units work. Commercial receivers start looking for a start bit leading edge as soon as the middle of the stop bit has been timed and checked. You need to do the same thing. You don't care when the end of the stop bit happens. You only care about the leading edge of the start bit which may be a bit earlier than the end of the stop bit as timed by the receiver. Others have posted in this thread by this point all the info you should need. If you still don't understand what is wrong with your understanding of the problem, let us know and we will try to make it more clear. > But I need to know what should I do with transmitter > module. As I attempted to explain, this half-bit solution cannot be used to > synchronize transmitters. It is a bad idea to start transmitting next byte > at the middle of the stop bit. It may fail listening device with slow clock > as it reaches center of stop bit when start bit of next byte is being > transmitted. On the other hand, if data is coming slightly faster > transmitter should do something, otherwise I face buffer overrun condition. > I understand that I can ignore the problem with transmitter module, it is > receiver that should synchronize with transmitter. However, I had got buffer > overrun problem until I used a trick described in my message (early > transmit). It is defenetely not the problem with receiver because I have > solved it right before got problem with transmitter's buffer overrun. And I > want to know how should function correct logic; there should be a solution > as commertial UARTs work without any problems. My UART is the first one > where I've realized that it is at all possible to get a problem with slowly > transmitting uart. > Is now the problem become clearer? To us, yes. Is it more clear to you as well? -- 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: 63591
Joel Kolstad wrote: > > Hal Murray <hmurray@suespammers.org> wrote: > >> You bright up a good subject, and you're absolutely correct that if you > >> continuously send data from one serial port at 9600.01bps to a receiver > >> at 9600, sooner or later there must be a buffer overflow. ... > > > > I think you are missing a key idea. The receiver has to make > > sure that it will tolerate early start bits. That is the receiver > > has to start looking for a new start-of-start-bit right after > > it has checked the middle of the stop bit rather than wait unitl > > the end of the stop bit to start looking. > > Unless your (slightly slower) transmitter also has the capability of > producing shortened start (or stop) bits, how those this approach 'fix' the > problem? If the date rates are, say, 9601 received BPS and 9600 transmitted > BPS, detecting early start bits just buys you one extra bit interval before > your overrun your buffers, doesn't it? No, by looking for the start of next word before the last word is complete, the receiver can receive data faster than you would calculate given the clock speed and the bit count. The receiver can receive data in 9.5 bit times per byte rather than the 10 bit times per byte the transmitter takes to send them. That is where the 0.5 bit or about 5% rate mismatch numbers come from. -- 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: 63592
sai a wrote: > > If anyone can help me with any information on the following, please do. > > 1. What exactly is a soft-core processor? I think it is one that is constructed with programmable logic using the normal programmable logic tools. This is in contrast to a hard-core processor, which is laid out in a more custom manner. Hard core processors can be present on an IC with programmable logic, but it is inserted as a single large piece of logic, rather than build with the standard programmable parts. Soft core is more flexible, but hard core has better performance: size, speed, low power. > 2. How do you go about building one? I suppose you either design your own with standard logic components or license an existing a design. I believe there is one processor design with some sort of free licensing. > 3. Are there any tutorials for this, with special reference to Handel-C? > 4. What are the tools required to build a soft-core using Handel-C? I added comp.arch.fpga to the group list. This should bring in some more knowledgeable folk. ThadArticle: 63593
Joel Kolstad wrote: > > Hal Murray <hmurray@suespammers.org> wrote: > >> You bright up a good subject, and you're absolutely correct that if you > >> continuously send data from one serial port at 9600.01bps to a receiver > >> at 9600, sooner or later there must be a buffer overflow. ... > > > > I think you are missing a key idea. The receiver has to make > > sure that it will tolerate early start bits. That is the receiver > > has to start looking for a new start-of-start-bit right after > > it has checked the middle of the stop bit rather than wait unitl > > the end of the stop bit to start looking. > > Unless your (slightly slower) transmitter also has the capability of > producing shortened start (or stop) bits, how those this approach 'fix' the > problem? If the date rates are, say, 9601 received BPS and 9600 transmitted > BPS, detecting early start bits just buys you one extra bit interval before > your overrun your buffers, doesn't it? I think I just understood what is wrong with my thinking. I was only looking at one direction. The problem the OP has is that he is looping back the received data and retransmitting it at the same slow(er) rate the receiver is using. Since the transmitter must use a full 10 bits, then the buffer between the receiver and transmitter will overflow at some point. This is a problem that is found in communications systems. All units must run at the same rate, but may use a different reference. So if they receive data at 8.0000 kHz and try to DAC it at 7.9999 kHz, about once per ten seconds there will be a byte too many and a sample will have to be dropped. This will cause a noticable click or other distortion of the voice. Some systems try to buffer this out, but that only postpones the problem. Most systems use a common reference that is very accurate and stable. Then the ADC and DAC clocks must be sync'd to the reference. I worked on a system that used a bendable VCXO to establish the 8 kHz rate. As the buffer data count varied from half full, the VCXO rate was increased or decreased by small amounts to keep the average rates matched. In the case of the OP, the first channel can use two stop bits and the echo channel can use one stop bit. This may not be pretty, but it will work. -- 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: 63594
On Tue, 25 Nov 2003, Austin Lesea wrote: > THE problem today however is drain source leakage. Out of curiosity there is a design approach that completly kill the Source-to-drain leakage; it's used in radiation environments. Unfortunatly all other performances are greatly reduced. It's published in Nucl. Instrum. Methods Phys. Res., A 439 (2000) 349-60 http://weblib.cern.ch/cgi-bin/ejournals?publication=Nucl.+Instrum.+Methods+Phys.+Res.,+A&volume=439&year=2000&page=349Article: 63595
Hi Rick et al., rickman <spamgoeshere4@yahoo.com> wrote: > Since the transmitter must use a full 10 bits, > then the buffer between the receiver and transmitter will overflow at > some point. I'm glad someone else agrees with me! I think we'd all agree now, then, that either you need an adjustable output clock or the part to transmit with a shortened stop (or start) bit, which is effectively the same thing as adjusting your output clock rate anyway. > This is a problem that is found in communications systems. All units > must run at the same rate, but may use a different reference. > Some systems try to buffer this out, but that only postpones the > problem. Most systems use a common reference that is very accurate and > stable. ...or they force the data to be encoded with its clock so that a PLL can extract the exact frequency reference and work with that. > In the case of the OP, the first channel can use two stop bits and the > echo channel can use one stop bit. This may not be pretty, but it will > work. It certainly will but the price is a reduction of ~10% of the average throughput! Of course, that may be negligible depending on the system. ---JoelArticle: 63596
yep! "Hans" <hansydelm@no-spam-ntlworld.com> wrote in message news:fVKwb.6988$4Y6.6456@newsfep4-winn.server.ntli.net... > Hi All, > > Thanks for all the suggestions and comments, I guess the next thing is too > simply buy one and try it out, > > Regards, > Hans. > www.ht-lab.com > > > > "louis lin" <louis@zyflex.com.tw> wrote in message > news:bpsik2$fpn@netnews.hinet.net... > > > > There's a tip on ISE5 of Xilinx: > > Please set the environment variable XIL_IMPACT_LPT2_BASE_ADDRESS to the > > base address used by your USB converter. > > It's worked on a PCI printer card in ISE5 / Windows 2000. > > However, I don't know if it will work on USB converter. > > > > > > > > "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com> > :3FC1B602.7000303@amontecDELETEALLCAPS.com... > > : Hans wrote: > > : > Hi All, > > : > > > : > I have recently received a new all singing all dancing (well nearly > :-) > > : > laptop but unfortunately it no longer has a serial or parallel port > (Dell > > : > 5150). In order to use my serial and parallel download/program cables > I need > > : > one of those USB to serial/parallel converters. > > : > > > : > Do they work (i.e. simulate a real parallel/serial port) or am I > asking for > > : > trouble? > > : > > > : > What about a PCMCIA parallel/serial card? > > : > > > : > Thanks > > : > > > : > Hans > > : > > > : > www.ht-lab.com > > : > > > : > > > : Hi, > > : > > : We tried months ago, but with only troubles. They do not come from > > : hardware, but from software ... all is depending on how the drivers are > > : written. > > : > > : Amontec annouced a new USB pod for Xilinx and Altera JTAG access. The > > : POD will be ready for Q1 2004. > > : > > : Laurent > > : www.amontec.com > > : > > : ------------ And now a word from our sponsor ------------------ > > : Want to have instant messaging, and chat rooms, and discussion > > : groups for your local users or business, you need dbabble! > > : -- See http://netwinsite.com/sponsor/sponsor_dbabble.htm ---- > > > >Article: 63597
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:<wJLwb.54017$hW7.28499@newssvr25.news.prodigy.com>... > "A.y" wrote: > > > 1. Can i assign flexible area constraints to individual modules in a > design.. > > Depends on your definitions of "flexible", but, yes, you can identify all > the logic for a given module and assign an area constraint to it. > > > i mean, can i say a module shud fit in this much area of some shape .. > > You can't say that a module "should fit" a given area. What you say is > something like "don't put logic for this module outside of this area". hello, yes i guess these were the better words .. but still, whether the tool really doesn't put the logic outside the area ? The > area has to be large enough for the grouped logic. Easiest way to find out > is to use the Floorplanner to gather the logic you want to constrain. While > creating the area constraint graphically, it will tell you what percentage > of the selected logic fits within the rectangle you are defining. > thank you very much for all explanation but .. > > without specifying absolute slice locations in area group ? .. and > Well, you do define an area within the chip. Not sure what you mean here. this was infact the "main" doubt that can i constrain the module within a area .. something like an rpm .. but not specify the coordinates of origin .. and definitely not the relative LOCS .. don't know how much it cud be better/worse information to the placement algorithm than other styles (rpm/area groups)! > If you want something that will maintain a given layout as you move it about > a chip you have to use RPMs. Even then, crossing certain boundaries gets > complicated (embedded multiplier columns). > i think rpms can cross such boundary.. not very sure .. my manually created rpm crossed it! > > 2. can structures other than rectangle be specified ? > > Sure, you can specify multiple rectangles to form other shapes. was not aware of that.. thanks a lot :) --ayArticle: 63598
Steve Lass <lass@xilinx.com> wrote in message news:<bq017p$ha32@cliff.xsj.xilinx.com>... > A.y wrote: > >In xilinx floorplanner or manualy (using ise 5.1) > >1. Can i assign flexible area constraints to individual modules in a design.. > >i mean, can i say a module shud fit in this much area of some shape .. > >without specifying absolute slice locations in area group ? .. and > > > You can specify that the module(s) should be grouped together, but you > can't specify the size and shape > unless you give it a location. > hello, thank you very much for the reply. could this have been be a useful facility ? if yes will it be available in future releases ? > >2. can structures other than rectangle be specified ? > > > You can put multiple rectangles together to form T, L, U, etc. shapes. > PACE is the easiest way to > create these area groups. > > Steve thank you very much ayArticle: 63599
"A.y" wrote: > but still, whether the tool really doesn't put the logic outside the > area ? Not sure I understand what you are asking here. If the area isn't large enough to contain the logic you constrained within it the tools will fail and issue an error. > this was infact the "main" doubt that can i constrain the module > within a area .. > something like an rpm .. but not specify the coordinates of origin .. > and definitely An area constraint, as far as I know, can only be done as an absolute location. That's one of the reasons a lot of people don't recommend you use them. They don't move easily from chip to chip. RPM's can move. This is particularly true if done intelligently and hierarchically from within HDL. For example, if you downsize your design from an XC2V2000 (say on a generic dev board) to an XC2V500. A lot of your area constraints won't make any sense at all. Hierarchically placed RPM's however, should retain their structure and might only require repositioning in order to port. > i think rpms can cross such boundary.. not very sure .. my manually > created rpm crossed it! Cross it they will. Cross it the way you thought they would, they may not. Look into RPM_GRID. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"
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