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
Simon Peacock <nowhere@to.be.found> wrote: > you guys seem to miss the point.. Async RS232 ALWAYS has mismatched clocks > ... ALL async UARTs MUST be capable of handling this.. that's why there's > flow control. There are a lot of systems in the world that don't use flow control and simply rely on a 'mutual agreement' between the interconnected devices that large streams of unbroken serial data isn't produced. This is especially the case of, e.g., sensors that produce real-time RS-232 output data with no buffering of their own -- in such a case flow control would just throw data away, so it's often not implemented to begin with. (I have a motto something to the effect of... if detecting an error does no more good than just ignoring it, you might as well ignore it... Although unfortunately this idea is often perverted into, 'if detecting an error takes effort, even if ignoring it causes the machine to rip off someone's arm, you might as well ignore it because otherwise the customer will immediately be able to pin the blame on you rather than having to guess whose fault it is.' :-( ) > You will find that 99.9% of them start looking for the start bit 1/2 way > thru the stop bit. If you want to build a repeater then you will need a > fractional stop bit generator OR you can over spec the crystal by 1.5% > (or the baud rate generator) OR you add RTS / CTS flow control like > everybody else. 1 -- The fractional stop bit generator is a good idea, and is apparently implemented in -- some -- commercial devices. This was news to me, but it does seem to be a very good solution. 2 -- Overclocking by 1.5% strikes me as a poor idea because the 'solution' is inherently non-scalable -- I can't connect together a dozen of these repeaters unless each one is progressively 1.5% faster, which isn't viable. 3 -- I'd agree that flow control is the 'proper' or 'textbook' solution, just that the real world doesn't always play by those rules. :-) ---Joel KolstadArticle: 63701
In article <3fc5e308$0$249$4d4ebb8e@read-nat.news.nl.uu.net>, Iwo_dot_Mergler@soton_dot_sc_dot_philips_dot_com says... > Klaus Falser wrote: > > Hello, In article <3fc5e308$0$249$4d4ebb8e@read-nat.news.nl.uu.net>, you say... > Klaus Falser wrote: > > Hello, > > > > I have a rather large design for a XC95288XL which consumes 276 macrocells > > of 288 possible. > > Since Xilinx seems to prefer Coolrunner devices to the good old XC9500's > > I tried to stuff the design into a Coolrunner II chip to look how it > > would behave. ..snip . > Have you constrained the design (pin assignments, etc)? What > is the fitter complaining about? > > There are some hard limits, like less OE lines than there are > outputs to a block. If, for instance, you are trying to create > a large GPIO device with more than 4 I/Os per block (8 are > possible) it won't work. > > Kind regards, > > Iwo > > No, for my first try I did not give any constrains, whether for pins nor for the timing. The I/O interface is bus-like, so the I/O lines share all the same OE. From my experience with the 9500's I have seen there are sometimes problems when creating a too large multiplexor, which comes from the available Product terms per macrocell. For instance, if you have a bus and you want to read back from more than 5 different registers, which implies a multiplexor before the output-pins, you have to distribute your pins carefully, since every macrocell with an output pin needs to steel PT from their neighbours. Coolrunner CPLD seems to have less PT inputs per macrocells, but give enough macrocells and without placing constraint I did expect some fit. Best regards -- Klaus Falser Durst Phototechnik AG kfalser@IHATESPAMdurst.itArticle: 63702
"Klaus Falser" wrote > > > No, for my first try I did not give any constrains, whether for pins nor for the > timing. > The I/O interface is bus-like, so the I/O lines share all the same OE. > From my experience with the 9500's I have seen there are sometimes problems when > creating a too large multiplexor, which comes from the available Product terms per > macrocell. > For instance, if you have a bus and you want to read back from more > than 5 different registers, which implies a multiplexor before the output-pins, > you have to distribute your pins carefully, since every macrocell with an output pin > needs to steel PT from their neighbours. > Coolrunner CPLD seems to have less PT inputs per macrocells, but give enough > macrocells and without placing constraint I did expect some fit. Comparing the two RPT files should give some guidelines ?. It is common for fitters to give better info, for a design that fits, so 'approaching the problem from (just) below' can be much more productive. When you have a partial design fitting, check the correct globals have been mapped OK. Missing a global resource can balloon usage. Sometimes the device package can have an influence - if there is more than one choice, get a report file for each package. -jgArticle: 63703
Thanks's for your answers! I've had a couple of bad experiences with different netbased companys myself - But it sounds like I've nothing to worry about in this case. - Only fair to let the guy's celebrate Thanksgiving without too much stress! :-) GNArticle: 63704
Dear Sir or Madame,
I have a question concerning the inputs of a VHDL module when
simulating with the Altera QuartusII Waveform Editor.
The input CONTROL shall be a registered signal from a different
module.
When doing a functional simulation I edit the waveform in that form you
can see so that CONTROL changes its value right with rising edge of
CLK. So I want to reproduce the registered input signal CONTROL.
But when starting the functional simulation I get the error message:
"Found clock-sensitive change during active clock edge ...", of course.
My question: How can I reproduce the clock synchronous input CONTROL without
violating setup-time? (using the Waveform Editor !!!)
Thank you for your help.
Andre V.
G&D System Development
-------- -------- --------
| | | | | |
| | | | | | CLK
| |___________| |___________| |___________
-------------------------------------------
|
| CONTROL
_____________________|
Article: 63705Hello! Thank you for your advice. Yes, I tried it the CoreGenerator. Hm. One more question: Do I have to copy the source code generated by the CoreGenerator in a vhd-file or is it enough to add the generated core (-> including the xco-file by saying: "New Source... IP(CoreGen & Architecture Wizard) in Xilinx ISE Foundation)? Tobias >Article: 63706
For discussion I include the code of fir example.
-- This is a generic FIR filter generator
-- It uses W1 signed bit data/coefficients bits
LIBRARY lpm; -- Using predefined packages
USE lpm.lpm_components.ALL;
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_arith.ALL;
USE ieee.std_logic_unsigned.ALL;
ENTITY fir_prog IS ------> Interface
GENERIC (W1 : integer := 9; -- Input bit width
W2 : integer := 18;-- Multiplier bit width 2*W1
W3 : integer := 19;-- Adder width = W2+log2(L)-1
W4 : integer := 11;-- Output bit width
L : integer := 4; -- Filter length
-- for Mpipe = 1 output Y_OUT is OK (PT)
Mpipe : integer := 3-- Pipeline steps of multiplier
);
PORT ( clk : IN STD_LOGIC;
Load_x : IN STD_LOGIC;
x_in : IN STD_LOGIC_VECTOR(W1-1 DOWNTO 0);
-- c_in : IN STD_LOGIC_VECTOR(W1-1 DOWNTO 0); -- (PT)
y_out : OUT STD_LOGIC_VECTOR(W4-1 DOWNTO 0));
END fir_prog;
ARCHITECTURE arch_fir OF fir_prog IS
SUBTYPE N1BIT IS STD_LOGIC_VECTOR(W1-1 DOWNTO 0);
SUBTYPE N2BIT IS STD_LOGIC_VECTOR(W2-1 DOWNTO 0);
SUBTYPE N3BIT IS STD_LOGIC_VECTOR(W3-1 DOWNTO 0);
TYPE ARRAY_N1BIT IS ARRAY (0 TO L-1) OF N1BIT;
TYPE ARRAY_N2BIT IS ARRAY (0 TO L-1) OF N2BIT;
TYPE ARRAY_N3BIT IS ARRAY (0 TO L-1) OF N3BIT;
SIGNAL x : N1BIT;
SIGNAL y : N3BIT;
SIGNAL c : ARRAY_N1BIT; -- Coefficient array
SIGNAL p : ARRAY_N2BIT; -- Product array
SIGNAL a : ARRAY_N3BIT; -- Adder array
BEGIN
Load: PROCESS ------> Load data or coefficient
BEGIN
WAIT UNTIL clk = '1';
IF (Load_x = '0') THEN
-- load coefs from X_IN input (PT)
c(L-1) <= x_in; -- Store coefficient in register
FOR I IN L-2 DOWNTO 0 LOOP -- Coefficients shift one
c(I) <= c(I+1);
END LOOP;
ELSE
x <= x_in; -- Get one data sample at a time
END IF;
END PROCESS Load;
SOP: PROCESS (clk, load_x) ------> Compute sum-of-products
BEGIN
IF clk'event and (clk = '1') THEN
FOR I IN 0 TO L-2 LOOP -- Compute the transposed
a(I) <= (p(I)(W2-1) & p(I)) + a(I+1); -- filter adds
END LOOP;
a(L-1) <= p(L-1)(W2-1) & p(L-1); -- First TAP has
END IF; -- only a register
y <= a(0);
END PROCESS SOP;
-- Instantiate L pipelined multiplier
MulGen: FOR I IN 0 TO L-1 GENERATE
Muls: lpm_mult -- Multiply p(i) = c(i) * x;
GENERIC MAP ( LPM_WIDTHA => W1, LPM_WIDTHB => W1,
LPM_PIPELINE => Mpipe,
LPM_REPRESENTATION => "SIGNED",
LPM_WIDTHP => W2,
LPM_WIDTHS => W2)
PORT MAP ( clock => clk, dataa => x,
-- this line to turn-off pipelining (PT)
-- PORT MAP ( dataa => x,
datab => c(I), result => p(I));
END GENERATE;
y_out <= y(W3-1 DOWNTO W3-W4);
END arch_fir;
Article: 63707Hi, since I upgraded the EDK 3.2 to 6.1 (with service pack 1) I'm having problems with debugging. To debug I do the following: - add next two lines to mss file PARAMETER DEFAULT_INIT = XMDSTUB PARAMETER DEBUG_PERIPHERAL = dbg_uart - set in makefile the optimization off (-O0) - set in makefile mode to xmdstub (instead of executable) - set in makefile compiler option -g (generating debug information) after downloading the bitfile, the program starts to run (very very slowly, but it runs! while I'm expecting that it should not run!). After starting xmd, I try to connect: mbconnect stub -comm serial -port com1 -baud 115200 and the next error was generated: XMD% mbconnect stub -comm serial -port com1 -baud 115200 ERROR: Unable to sync with stub on the board using the UART Closing serial port Unable to establish connection to xmdstub Unable to connect to MicroBlaze Target Does anyone have an idea? The described procedure was working with EDK 3.2 and ISE 5.2... Thanks, FrankArticle: 63708
Jim, Been there, done that. Still doing that, and more. It is very favorable to do special things with the cmos configuration cells (we call them CCC's) rather than SRAM memory for configuration. Our CCC's are 20X or more robust than SRAM to SEUs, and all for good reasons. Austin Jim Granville wrote: > "Nicholas C. Weaver" > >>In article <vsclib1e0fi69b@corp.supernews.com>, >>Hal Murray <hmurray@suespammers.org> wrote: > > <snip> > >>>Any reason somebody couldn't implement 2 types of logic on one >>>chip. Slow but low leakage for the config memory and fast but >>>more leakage for the active logic? I assume it doesn't work >>>easily with modern processing or people would be doing it already. >>>(Maybe they already are?) > > > I believe foundries offer this already. > > Maybe Austin L could confirm if Xilinx are using this ? > > In noise immunity topics, we've seen the point made that > the CONFIG cells have significantly different, and better, noise > immunity ( so config corruption is less likely than logic corruption). > > >>>I'm fishing for more theory or long term ideas. >> >>The problem is the FPGA places the SRAM cells (low leakage) right next >>to active (must be high speed) switching transistors. >> >>Any processing rule which had two Vts for the different transistors >>would probably require a fairly substantial spacing between the two >>types. > > > Why ? Sure, more steps will be needed - but spacing ? > > There would be a case for really pushing the Speed rules for LOGIC, > but going for MAX Yield (ie slightly relaxed geometries) on the CONFIG > cells (lots more of them, _and_ they are not 'picosecond paranoid' ). > There would be some trade off on CONFIG time, and leakage Current in > a variable threshold design. > > I think this could be checked experimentally - drop Vcc, and LoadCLK, > and plot Config verify fail Vcc/Freq curve. > Then create a LOGIC fabric shifter, and do the same for it. > > -jg > >Article: 63709
Tullio, The spec is for cycle to cycle jitter, not for peak to peak. If your signal has 1 ns of cycle to cycle jitter, it would all but unusable for just about anything. Hopefully, that is not the case, and the signal has 1 ns of peak to peak jitter. If you were to measure the cycle to cycle jitter of this signal, it will have to be less than the 300 ps +/- DCM input specification (which is most likely). There is also the "jitter filter" attribute which should be set to 0xFFFFh for real jittery input signals, as this will allow the DCM to track the incming signal the fastest (to prevent one cycle jitter to the next cycle of jitter from affecting the phase detector). The status signals will properly indicate the operation: if locked does not go high at all, or if it goes high, and then goes low a few thousand clock cycles later, it is an indication of too much jitter. I have tested the DCM with sine wave jitter (at one frequency) from 100 KHz to 20 MHz with much more than 1 ns of p-p jitter, and have seen no issues at all, because the cycle to cycle jitter is much less than the input specification. The DCM is completely insensitive to input jitter frequency (within the range that was tested). For example, if in 1 microsecond (1 megahertz), a 100 MHz clock signal had 1ns of jitter, peak to peak, then there are 100 clock cycles per jitter modulation period (1 us), and the cycle to cycle clock jitter is 1/100 of the peak to peak (or 10 ps). Austin Tullio Grassi wrote: > The VirtexII data sheet requires an input jitter for > the DCM smaller than + or - 300 ps (in Low Frequency Mode). > Obviously this ensures the proper behavior across all > permitted frequencies and modes. > > In my case I have an input clock with 1ns of pk-pk jitter, but > it is a 40 MHz clock, that I only need to shift by 90 (clk90), > and to multiply by 2 (clk2x) other than having a locked version > (clk0) of the original clock. > How can I verify if it still works reliabily ? > Or is the going to DCM loose lock ? > Or will the phase relationships btw the output clocks not met ?Article: 63710
Ian wrote: >Hello All, > >I am having problems running the modular design flow in Xilinx ISE >6.1. > >Everything seems OK until I configure (Spartan2 via Boundary Scan >/Parallel using Impact) I get a programming failed message - the done >pin failed to go high. I have tried a few different options in Bitgen >with no success. > >Also, the Xilinx ISE 'development systems reference guide' and the >Xilinx answers database seem to conflict on the correct use of ngo/ngd >files in the modular flow. i.e. > >Development Systems Reference Guide, Modular Design Section, Top of >Page 93 (PDF version) > >“Note: ngdbuild produces two files, design_name.ngd and >design_name.ngo. The design_name.ngo file is used during subsequent >Modular Design steps, while design_name.ngd is not.” > >BUT......... > >Xilinx Answer Record # 17058 6.1i Modular Design >(http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=17058) > >“An NGO file is produced only if an EDIF netlist is used as the >input to NGDBuild. The NGC netlist created by XST is already in Xilinx >Database Format, and does not need to be converted to an NGO >file.” > > >So could the fact a am using the NGC netlist produced by ngdbuild >instead of the ngo file prescribed by the Development Systems Ref >Guide be causing this problem?? > No. NGC and NGO have essentially the same info, so the NGC can be used in the modular design flow. We'll fix the reference guide to say that NGC and NGO can be used. I suspect your problem is related to downloading into the FPGA. Steve > >Please Help (Its nearly Christmas!) > >Ian Colwill, University Of Sussex, UK > >Article: 63711
Hello! If I use the CoreGenerator (for example in order to configure a Dual Port Ram) do I have to copy the source code generated by the CoreGenerator in a vhd-file or is it enough to add the generated core (-> including the xco-file by saying: "New Source... IP(CoreGen & Architecture Wizard) in Xilinx ISE Foundation)? Isn't it possible just to use the xco-file, generated by the CoreGenerator? Or do I have to add a vhd- file in addition? Tobias.Article: 63712
Suppliers don't become market leaders by discontinuing 90% of their product lines. There is a clear note in the document referenced that highlights "selected products"; Altera is not obsoleting any product lines. We do selectively prune ordering codes (i.e. speed grades, packages, or extended temp products) when demand is extremely low; during this process we issue product discontinuation notices (PCNs). Altera also provides a site to search for all obsolete devices at: http://www.altera.com/products/devices/common/dev-obsolete_device_search.html. The actual number of obsoleted products is ~ 2% not 90%. I think this site would be better served without incorrect competitive FUD. Dave Greenfield Altera Corporation > 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! > > >Article: 63713
Amirix has a V2Pro eval board with gig ether support, but it doesn't go up to the 70 (7, 20, or 30 I think). I know that they have people using it to play with Gig ether, and it has support for the PowerPC core, and a separate Ether as well. www.amirix.com ----- Ron Huizen BittWare "Anup Kumar Raghavan" <anup@csee.uq.edu.au> wrote in message news:3FC9F71E.A44B8F55@csee.uq.edu.au... > Can I get suggestions for FPGA development boards that house the > XC2VP70/125 Virtex 2 Pro FPGA? I have read the DINI specs and they seem > to be the only one I can find that supports this FPGA. I want a board I > can use to test network protocols like gigabit ethernet, and hence want > to hook up either fibre or coax-ethernet cable to the board. > > Thanks > Anup > >Article: 63714
I am innocent, but let me apologize on behalf of Xilinx. We should all make sure that our information is correct, and especially so when we mention the competitor. Let's stay away from mudslinging! Peter Alfke =================== Dave Greenfield wrote: > I think this site would be better served without incorrect competitive > FUD. > > Dave Greenfield > Altera Corporation > >Article: 63715
PawelT wrote:
> Hello,
> I tried to simulate example of generic FIR filter on page 82 from
> book Uwe Meyer "Digital Signal Processing with FPGAs".
> In book in simulation the first valid output is after 475 ns and zeros
> before that.
> I tried this example with MAxplus2 Baseline v10.2 and with new
> ACF-file. Does anybody compile this?
> After compilation and simulation on outputs Y_OUT there is appeared
> unexpected new value dec*2046* after 125ns till 325ns,
> and after 475 ns there is "correct" value from book.
> And my question is: why this *unexpected* value (2046) appeared ?
I'm guessing that since your flip-flops are not initialized upon reset,
what you are seeing is the time it takes for your filter taps (and
coefficients?) to settle down with valid values. For many designs, this
type of behavior is not a problem. - but you'll have to be the judge of
that for your situation.
> After that I tried change number of pipeline stages in lpm_mult, and
> this *unexpected* value disappeared when constant Mpipe=1. For
> Mpipe=2,3,4 there is bad value....
[...
> May I attache this source vhdl code on usenet?
Of course. It often helps in diagnosing problems.
> I think about copyrights..
Once posted to usenet, you have little control of the code. You can
place a copyright on it, but enforcement can be near impossible.
Marc
Article: 63716On a sunny day (30 Nov 2003 18:54:40 -0800) it happened huangphoenix@hotmail.com (deadflower) wrote in <3cfa6819.0311301854.56386fdd@posting.google.com>: >Hi, group, > >I plan to buy digilent combo board DIO2 combo. Does anybody know if a >download cable will be included in the package? Yes parallel port >also, do they provide >the software like foundation or webpack? NoArticle: 63717
I have seen much conflicting advice w.r.t timing constraints on this newsgroup, and I was hoping that the proponents of both camps might make explicit their reasons so that others (meaning I ;) can benefit from their experience. I have seen many posts recommending over-constraining the timing requirements in an effort to ensure correct functioning in the presence of uncertainty and unknowns, but I have also seen many posts stating that the tools are now good enough that this is no longer necessary, and that giving the true timing constraints is sufficient, and will allow more latitude for the tools to put their effort where it is truly needed. I doubt if it's so cut-and-dry, but which is the "right" one? Or have I completely misunderstood the problem? Thanks for your time, Pierre-Olivier --To reply directly, remove the obvious in pl_N0SP4M_apri@cim.mcgill.1NV4LID.ca--Article: 63718
Hi Frank, Frank wrote: > > Hi, > > since I upgraded the EDK 3.2 to 6.1 (with service pack 1) I'm having > problems with debugging. To debug I do the following: > > - add next two lines to mss file > > PARAMETER DEFAULT_INIT = XMDSTUB > PARAMETER DEBUG_PERIPHERAL = dbg_uart > > - set in makefile the optimization off (-O0) > - set in makefile mode to xmdstub (instead of executable) > - set in makefile compiler option -g (generating debug information) > > after downloading the bitfile, the program starts to run (very very slowly, > but it runs! while I'm expecting that it should not run!). After starting If your download.bit contains xmdstub (typically the case for XMDSTUB mode), the xmdstub starts to execute after the bitfile is downloaded.. After the following changes in mss file, did you update your bitstream ? > xmd, I try to connect: > > mbconnect stub -comm serial -port com1 -baud 115200 > > and the next error was generated: > > XMD% mbconnect stub -comm serial -port com1 -baud 115200 > ERROR: Unable to sync with stub on the board using the UART > Closing serial port > Unable to establish connection to xmdstub > Unable to connect to MicroBlaze Target Looks like your download.bit file does not contain xmdstub. Updating the bitstream should have xmdstub in your design. There is no change in EDK6.1 and the design should work. -Raj > > Does anyone have an idea? The described procedure was working with EDK 3.2 > and ISE 5.2... > > Thanks, > FrankArticle: 63719
PO Laprise wrote: > I have seen much conflicting advice w.r.t timing constraints on this > newsgroup, and I was hoping that the proponents of both camps might > make explicit their reasons so that others (meaning I ;) can benefit > from their experience. > > I have seen many posts recommending over-constraining the timing > requirements in an effort to ensure correct functioning in the > presence of uncertainty and unknowns, but I have also seen many posts > stating that the tools are now good enough that this is no longer > necessary, and that giving the true timing constraints is sufficient, > and will allow more latitude for the tools to put their effort where > it is truly needed. I doubt if it's so cut-and-dry, but which is the > "right" one? Or have I completely misunderstood the problem? I try to enter the constraints that exactly match the timing that the design will need to function, including board delay, loading delay, clock jitter and clock skew. Xilinx tools will now allow for a clock jitter number, and will add jitter when going through DCMs. So the tools are (maybe) somewhat better. But the rest still needs at least minimal work, and maybe a lot of work if the timing is tight. -- Phil HaysArticle: 63720
In article <3FCC13DB.8F643B8F@attbi.com>, Phil Hays wrote:
> I try to enter the constraints that exactly match the timing that the
> design will need to function, including board delay, loading delay,
> clock jitter and clock skew.
Don't forget metastability slack. In theory it does not apply to the
purely synchronous nets; in practice I don't want to go through the
work of separating them out, and it's a good excuse to add one more
conservative assumption.
- Larry
Article: 63721"Larry Doolittle" <ldoolitt@recycle.lbl.gov> wrote in message news:slrnbsoacg.9j2.ldoolitt@recycle.lbl.gov... > In article <3FCC13DB.8F643B8F@attbi.com>, Phil Hays wrote: > > I try to enter the constraints that exactly match the timing that the > > design will need to function, including board delay, loading delay, > > clock jitter and clock skew. > > Don't forget metastability slack. In theory it does not apply to the > purely synchronous nets; in practice I don't want to go through the > work of separating them out, and it's a good excuse to add one more > conservative assumption. > > - Larry Larry - What is metastability slack and how do you apply it? Do you mean you over-constrain your clock periods slightly to expand setup margins? Thanks, RobertArticle: 63722
Phil Hays wrote: > PO Laprise wrote: >>I have seen much conflicting advice w.r.t timing constraints on this >>newsgroup, and I was hoping that the proponents of both camps might >>make explicit their reasons so that others (meaning I ;) can benefit >>from their experience. >>I have seen many posts recommending over-constraining the timing >>requirements in an effort to ensure correct functioning in the >>presence of uncertainty and unknowns, but I have also seen many posts >>stating that the tools are now good enough that this is no longer >>necessary, and that giving the true timing constraints is sufficient, >>and will allow more latitude for the tools to put their effort where >>it is truly needed. I doubt if it's so cut-and-dry, but which is the >>"right" one? Or have I completely misunderstood the problem? > I try to enter the constraints that exactly match the timing that the > design will need to function, including board delay, loading delay, > clock jitter and clock skew. > Xilinx tools will now allow for a clock jitter number, and will add > jitter when going through DCMs. So the tools are (maybe) somewhat > better. But the rest still needs at least minimal work, and maybe > a lot of work if the timing is tight. How about temperature or Vcc variation? Or process variations in the chips? A newer chip batch, done on a different process, may be faster than an older one. If the timing constraints already include such margins, you don't need to add additional margins. -- glenArticle: 63723
"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> wrote in message news:bqeqiq$654$1@news.oregonstate.edu... > Simon Peacock <nowhere@to.be.found> wrote: > > you guys seem to miss the point.. Async RS232 ALWAYS has mismatched clocks > > ... ALL async UARTs MUST be capable of handling this.. that's why there's > > flow control. > > There are a lot of systems in the world that don't use flow control and > simply rely on a 'mutual agreement' between the interconnected devices that > large streams of unbroken serial data isn't produced. This is especially > the case of, e.g., sensors that produce real-time RS-232 output data with no > buffering of their own -- in such a case flow control would just throw data > away, so it's often not implemented to begin with. (I have a motto > something to the effect of... if detecting an error does no more good than > just ignoring it, you might as well ignore it... Although unfortunately this > idea is often perverted into, 'if detecting an error takes effort, even if > ignoring it causes the machine to rip off someone's arm, you might as well > ignore it because otherwise the customer will immediately be able to pin the > blame on you rather than having to guess whose fault it is.' :-( ) > > > You will find that 99.9% of them start looking for the start bit 1/2 way > > thru the stop bit. If you want to build a repeater then you will need a > > fractional stop bit generator OR you can over spec the crystal by 1.5% > > (or the baud rate generator) OR you add RTS / CTS flow control like > > everybody else. > > 1 -- The fractional stop bit generator is a good idea, and is apparently > implemented in -- some -- commercial devices. This was news to me, but it > does seem to be a very good solution. > 2 -- Overclocking by 1.5% strikes me as a poor idea because the 'solution' > is inherently non-scalable -- I can't connect together a dozen of these > repeaters unless each one is progressively 1.5% faster, which isn't viable. > 3 -- I'd agree that flow control is the 'proper' or 'textbook' solution, > just that the real world doesn't always play by those rules. :-) > Actually you can :-) Data is only sent at the speed it arrives at.. so although you are 1.5% fast.. you actually end up adding extra stop bits into the stream to compensate .. is simple and oh so clever. This is exactly what modems did for years to cope with the V.14 shaved bits when they couldn't do them. SimonArticle: 63724
HI Simon, Simon Peacock <nowhere@to.be.found> wrote: > Data is only sent at the speed it arrives at.. so although you are 1.5% > fast.. you actually end up adding extra stop bits into the stream to > compensate .. is simple and oh so clever. Well, fair enough, if you KNOW that your data source is truly supposed to be 'nominally,' say, 9600bps, then you can be clever and get away with an internal nominal bit rate of 9600*1.015=9744bps. However, if you tell me you have such a device that you'd like to connect to one of my devices, you'd better be able to convince me there really is no way your device could start spewing data continuously at 9744 bps when my 9600 bps receiver isn't going to be able to hack it! >This is exactly what modems did > for years to cope with the V.14 shaved bits when they couldn't do them. Interesting; I didn't know that either! ---Joel
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