Simple Verilog RS232 Receiver - ETO Exclusive

[BrownOut]

A DESIGN ENGINEER! Ooooooooohhhhh... I"m soooooo impressesd LOL! I guess it's just too big a blow to your ego that someone can create a perfectly working system without the need of your expertise. I don't recall asking you if my module was a profession grade one, in fact, I think I was very, very clear this is a simple module from which a fuller solution can be developed. You might know alot about standards, but you don't know jack about reading and understand the purpose and scope of projects. The module I've posted was not targeted for a professional application, rather as a means of verifying the comm channel from my computer through the physical connections to the FPGA. But, it could be easily made to function in a professional application, as there is virtually no difference between it and other "soft" UARTS being used by professoinals all over the marketplace.

The most hilarious thing about your tirades is you spend days harping about how the standard doesn't cover UART design, then turn right around and start harping how the UART design isn't what the standard specifies. I always say if you give a bloviator enough time, he'll begin to argue with himself LOL!

To recap, this module is a simple receiver for connecting to a computer’s RS-232 port and communicating with an FPGA development board that includes an RS-232 comm port. It can be used as a stand alone receiver, or as a bases for a more fully functional UART. No claim is made that this is a professional design and no guarantee is made that it will satisfy any professional requirements. It should provide for very good, basic communications between the PC and a development board, however, as it’s functionality is virtually identical to that of more advanced UART receive channels.
That should be simple enough for anyone.

 

[Ubergeek63]

It can be used as a stand alone receiver, or as a bases for a more fully functional UART. No claim is made that this is a professional design and no guarantee is made that it will satisfy any professional requirements. It should provide for very good, basic communications between the PC and a development board, however, as it’s functionality is virtually identical to that of more advanced UART receive channels.
That should be simple enough for anyone.

You really are a git aren't you?

Take your static gun, ground it to system ground and set it for 10KV. Expose your receive wire and hit it with a 100 discharges through the air while you are receiving continuous data. IF your board does not blow out (it won't if it has a 15KV RS232 chip on it) you WILL get data errors. A REAL UART takes multiple samples and would NOT get data errors.

oh wait, I forgot, you are just an egomaniac hobbyist that would not know a static gun if he tripped over one!

 

[BrownOut]

Why don't you take your static gun and point it to that place the sun doesn't shine and see how many errors you get?

Every real UART I’ve looked at uses the same sampling as my simple receiver does.

Oh, but you are sooooo much more knowledgeable than everyone else! Don't expect anyone to fall on their knees in front of you, chanting, "How great UART!" LOL!

 

[Ubergeek63]

Why don't you take your static gun and point it to that place the sun doesn't shine and see how many errors you get?

Every real UART I’ve looked at uses the same sampling as my simple receiver does.

Oh, but you are sooooo much more knowledgeable than everyone else! Don't expect anyone to fall on their knees in front of you, chanting, "How great UART!" LOL!

**broken link removed**
Interface - UARTs - TL16C2752 - TI.com

you might try looking at the TI UART page and explain to me what the "Baud Rate (max) at Vcc = 2.5V and with 16X Sampling (Mbps)" column means in the context of your never having seen a UART that samples more than yours. the fact is that 19 out of the 26 UARTs is 16x oversampled, and yet the only clue that they do in the data sheet is NOT in the pictures but in the 16x clock rate...other than that the fact is not mentioned, it is assumed you know it.

it is, in fact, the only reason RS232 can go at a reasonable speed. The plain fact is that MOST of the UARTs that you have seen are most likely 16x oversampling and you just did not know it since they do not show it in the cartoons.

 

[BrownOut]

By: Ubergeek63 you might try looking at the TI UART page and explain to me what the "Baud Rate (max) at Vcc = 2.5V and with 16X Sampling (Mbps)" column means in the context of your never having seen a UART that samples more than yours. the fact is that 19 out of the 26 UARTs is 16x oversampled, and yet the only clue that they do in the data sheet is NOT in the pictures but in the 16x clock rate...other than that the fact is not mentioned, it is assumed you know it.

it is, in fact, the only reason RS232 can go at a reasonable speed. The plain fact is that MOST of the UARTs that you have seen are most likely 16x oversampling and you just did not know it since they do not show it in the cartoons.

I can easily explain that to you. But you haven't said you think it means yet. I'll bet it doens't mean what you think it does.

 

[Ubergeek63]

I can easily explain that to you. But you haven't said you think it means yet. I'll bet it doens't mean what you think it does.

I KNOW what it means... 75-90% of ALL UARTs these days oversample the incoming data stream to sink up (they register errors if they detect partial bits in an incoming word) and to reject EMI.

It also means that you are following the idealized cartoons of what is more the THEORY behind it as opposed to what "new" hardware does. NEW is in quotes because it has been MANY years since they started oversampling in UARTs as the RULE rather than the exception.

It also shows you for being a twit who has backed himself into a corner and refuses to admit his errors. It is a FACT that you claimed that your code was "essentially the same as in real UARTS" I have proven beyond a shadow of a doubt that it is SIGNIFICANTLY different from real UARTs.

I started with simple calm points and you reviled against them. Now here we are, you stamping your feet having a temper tantrum thinly veiled with false humor while accusing me of doing the same. I bring facts to the table, at first just as simple point though I do get real tired of being called a fool for stating the basic facts of electronics ... has a lot to do with a piss ant contract twit calling me a fool in the same way you did and never admitting HIS errors.

The FACT that you got some marginal theoretical code working in an ideal environment does not make it anything close to what is in the industry UARTs. Nor will it protect the fool that puts it in a noisy environment doing a potentially critical control function on your say so.

Today UARTs sample the incoming signal at 16 times the bit rate, average the samples in every bit over the 10 bit word, and assemble it appropriately. If the start or start bit is no good it will flag the byte as bad. If the UART detects a questionable bit it will flag the byte as bad.

You are inordinately proud of the async receiver. If you want to do something worthy of pride, do a 16x over sampler that takes over 10 high samples as a high, under 6 as a low. For a single damaged bit, use the parity bit to fix it. Then you WILL have something similar to, if not better than, a generic UART receiver.

 

[BrownOut]

WRONG! You've totally misinterpreted the meaning of oversampling... which make you the twit! You’ve proven nothing, you've shown nothing and you've added nothing to the discussion, other than your lack of understanding of how these modules work. 16x and so forth oversampling is nothing more than a reference clock running at 16 times the baud rate, in order to find the optimum sampling point in the data period. No UARTs are actually using 16 samples each period to reduce errors! LOL!

I've looked at the code used to realize "real" UARTS. They certainly do not, never, never ever use 16 bits in any kind of majority voting circuit to do anything close to reducing errors. That's not just ridiculous, but completely made up on your part so you may disparage a perfectly good, perfectly working, perfectly suitable module and I shared with the group. You've totally trolled the thread. You must have a real problem with someone else making something that works.

OK, so you're so much smarter than everyone else, then why don't you show us all how to modify the code to realize your totally worthless, over complicated and unnecessary error reduction scheme. C'mon, super DESIGN ENGINEER dude, show us what you got. You said any fool can do it. C'mon, meat! Dazzle with your brilliance! Show us you are so superior to all of us poor, ignorant fools who can't make anything worthwhile. This should be such an easy exercise for you, since you probably do it in your sleep, so show us how it's done! Make us all your engineering bitches!

OH, and since you still aren't reading my posts. I'll just repeat this for your benefit:

To recap, this module is a simple receiver for connecting to a computer’s RS-232 port and communicating with an FPGA development board that includes an RS-232 comm port. It can be used as a stand alone receiver, or as a bases for a more fully functional UART. No claim is made that this is a professional design and no guarantee is made that it will satisfy any professional requirements. It should provide for very good, basic communications between the PC and a development board, however, as it’s functionality is virtually identical to that of more advanced UART receive channels.

Do you get it yet? I never made any claim that this will work in every environment, in every application. I said from the start that this is a SIMPLE way to communicate with an PFGA, never did I made any cliam it should be used to do anything else. You continue to use fake and phony claims to rip it up. Claims I never made. The simple code I made is comparable to code used to make real UARTS. If you can prove otherwise, then do it. If you can't, they you're bringing nothing and saying nothing.

Here is code form a real UART. It's from the 16550 you pimped earlier as a real UART:

	sr_rec_prepare:begin
				case (lcr[/*`UART_LC_BITS*/1:0])  // number of bits in a word
				2'b00 : rbit_counter <= #1 3'b100;
				2'b01 : rbit_counter <= #1 3'b101;
				2'b10 : rbit_counter <= #1 3'b110;
				2'b11 : rbit_counter <= #1 3'b111;
				endcase
				if (rcounter16_eq_0)
				begin
					rstate		<= #1 sr_rec_bit;
					rcounter16	<= #1 4'b1110;
					rshift		<= #1 0;
				end
				else
					rstate <= #1 sr_rec_prepare;
				rcounter16 <= #1 rcounter16_minus_1;
			end
	sr_rec_bit :	begin
				if (rcounter16_eq_0)
					rstate <= #1 sr_end_bit;
				if (rcounter16_eq_7) // read the bit
					case (lcr[/*`UART_LC_BITS*/1:0])  // number of bits in a word
					2'b00 : rshift[4:0]  <= #1 {srx_pad_i, rshift[4:1]};
					2'b01 : rshift[5:0]  <= #1 {srx_pad_i, rshift[5:1]};
					2'b10 : rshift[6:0]  <= #1 {srx_pad_i, rshift[6:1]};
					2'b11 : rshift[7:0]  <= #1 {srx_pad_i, rshift[7:1]};
					endcase
				rcounter16 <= #1 rcounter16_minus_1;
			end
sr_end_bit :   begin
				if (rbit_counter==3'b0) // no more bits in word
					if (lcr[`UART_LC_PE]) // choose state based on parity
						rstate <= #1 sr_rec_parity;
					else
					begin
						rstate <= #1 sr_rec_stop;
						rparity_error <= #1 1'b0;  // no parity - no error :)
					end
				else		// else we have more bits to read
				begin
					rstate <= #1 sr_rec_bit;
					rbit_counter <= #1 rbit_counter - 1'b1;
				end
				rcounter16 <= #1 4'b1110;

Now, show me where 16 samples are being collected and used in any error reduction scheme. If you can't then your whole tirade has bee nothing more than an attempt to rip up a perfect design. Also, I'm still waiting for you to explain to me how a UART cannot satisfy a standard that you've claimed does not cover the design of the UART?

OH, and one more thing, you're the one who started calling people 'fools' so don't cry when someone ruffles your feathers.

 

[Ubergeek63]

Now, show me where 16 samples are being collected and used in any error reduction scheme. If you can't then your whole tirade has bee nothing more than an attempt to rip up a perfect design. Also, I'm still waiting for you to explain to me how a UART cannot satisfy a standard that you've claimed does not cover the design of the UART?

OH, and one more thing, you're the one who started calling people 'fools' so don't cry when someone ruffles your feathers.

Actually you are boring me and I was getting tired of looking for something that Big Business (BB) does not want you to know ... particularly when it is cutting into my time with my wife, my games, and my job...

You see BB loves it's "Intellectual Property", "Trade Secrets", and "Patents" (mostly themselves secretly hiding the fact that they are unenforceable due to the "prior art" that the "patent" holder knows full well exists).

In this case it is buried in a vague box called "data validation" like the one on page 27: https://www.electro-tech-online.com/custompdfs/2010/05/NS16C2552.pdf if you are lucky. Unfortunately in is usually completely hidden by terms like "framing error" and "link fault".

Luckilly I have tracked down an HONEST description since you are determined not to believe anyone but yourself: https://www.macrocad.com/doc/vcm8251.pdf Which of course begs the question of why I should bother... oh that's right, someone actually interested in learning something might be following this...

If you look on page 7 you see a number of phrases, however the one that we have been discussing is:

"Serial Data Sampling

The serial input bit stream can be sampled with either 7 or 3 of the 16x clocks. A majority voting scheme is employed in these windows."

Which is EXACTLY what I was saying. Obviously if you turn off the parity bit there is no way to do data recovery on the bytes, my point was that a UART could easily determine if it lost a single bit is a "voting" scheme and correct it with the parity bit. The majority voting scheme in sampling UARTs, is robust, but not fault tolerant. Keeping track of every sample would allow logic to use the parity bit to correct single bit errors by instead of simply a majority splitting the sample into three pieces to create a third "bad bit" state to be corrected by the parity bit creating a bytewise fault tolerant system.

 

[BrownOut]

So, you're not telling me anything I didn't already know. You're claim is that in order for a UART to be a real UART, it must take multiple samples. Now, you've found one that does, but that doesn't mean it's the only way for a real UART to be made. It also said may be sampled by 7 or 3 of the 16x clocks. But you said above that all 16 samples are used, and that that's how real UARTS work, and anything else isn't reliable. 7 bits would seem to me to be the maximum bits from a 16x clock that could reliably be captured; otherwise, the samples would be taken from unreliable portions of the data period.

Sorry, you've still failed to prove anything claim you made about my little design. Finding one UART that uses the sampling technique does not mean that's what a real UART must use. You choose to ignore the real UART that I posted above, and that's OK. But my point is proved, that it's still a real UART if it uses the sampling technique that I've used, and is a reasonably reliable way to communicate.

Far from boring me, you've provided me with much entertainment over the last couple days, as you've tried to distort and make up phony requirements, even attempted to show an over-complicated, unnecessary scheme that wouldn't work. I've had plenty of smiles reading your desperate posts, including this one in which you think you've proved that all real UARTS much use multiple samples/majority voting just because you've found one that does. BTW, that's still way more simple than the convoluted scheme you described I would need to implement before I can feel proud of my creation.

From your first post:

1. At the falling edge of the start bit, an internal timer starts
counting at 16X clock. At 8th 16X clock, approximately
the middle of the start bit, the logic level is sampled. If a
logic 0 is detected the start bit is validated.
2. The validation logic continues to detect the remaining
data bits and stop bit to ensure the correct framing. If an
error is detected, it is reported in LSR[4:2].
3. The data frame is then loaded into the RBR and the
Receive FIFO pointer is incremented. The error tags are
updated to reflect the status of the character data in RBR.
The data ready bit (LSR[0]) is set as soon as a character
is transferred from the shift register to the Receive FIFO.
It is reset when the Receive FIFO is empty.

YUP, that's pretty much the way I do it.


I don't buy the "trade" secrets, since majority voting and such are well known techniques. Manufacutres don't hide features, they market them! That they are used in some UARTS does not prove they must be used in all real UARTS.

 

[Ubergeek63]

So, you're not telling me anything I didn't already know. You're claim is that in order for a UART to be a real UART, it must take multiple samples. Now, you've found one that does, but that doesn't mean it's the only way for a real UART to be made. It also said may be sampled by 7 or 3 of the 16x clocks. But you said above that all 16 samples are used, and that that's how real UARTS work, and anything else isn't reliable. 7 bits would seem to me to be the maximum bits from a 16x clock that could reliably be captured; otherwise, the samples would be taken from unreliable portions of the data period.

What? that is 16 samples PER BIT not per BYTE... and were it per byte you would not be getting everything as there are a minimum of 10 bits per full byte(1 START, 8 DATA, 1 STOP)

Sorry, you've still failed to prove anything claim you made about my little design. Finding one UART that uses the sampling technique does not mean that's what a real UART must use. You choose to ignore the real UART that I posted above, and that's OK. But my point is proved, that it's still a real UART if it uses the sampling technique that I've used, and is a reasonably reliable way to communicate.

I never said you did not get it working, I said it was not robust and would be unreliable in a noisy environment

Far from boring me, you've provided me with much entertainment over the last couple days, as you've tried to distort and make up phony requirements, even attempted to show an over-complicated, unnecessary scheme that wouldn't work. I've had plenty of smiles reading your desperate posts, including this one in which you think you've proved that all real UARTS much use multiple samples/majority voting just because you've found one that does. BTW, that's still way more simple than the convoluted scheme you described I would need to implement before I can feel proud of my creation.

What I said was that is it more common than not for oversampling to be used to filter out noise. What I described was only the beginning of what would be used in a mission critical military application, does that mean that I expect you to implement it? Certainly not. All that really needed was the realization that it would indeed be more reliable. None of it is needed if you are on PC board, a short cable, or running at low speed... your current situation is the latter two in a low EMI environment

I don't buy the "trade" secrets, since majority voting and such are well known techniques. Manufacutres don't hide features, they market them! That they are used in some UARTS does not prove they must be used in all real UARTS.

On the contrary, manufacturers do all that they can to claim and maintain perceived superiority. A more common example would be in jewelry... QVC's "Diamonique" is just cubic zirconia and HSN's "Technibond" is just vermeil (gold plated silver). They do all they can to maintain the perception that they are better ... if that means coming up with some cock and bull trade name that is what they will do. Case in point is National Semiconductor's "Solar Magic": all sorts of demonstrations and gymnastics all to keep out of the literature what it really is: Maximum Power Point Tracking.

What it boils down to is that it is not in their best interest to tell you how it does it, only what they can play up as being better than their competition. Marketing is about deception, while they can not out right lie they can distort things leading you to believe what they are doing is a bit different and that difference makes it work so much better that it is worth your while to pay more for the product.

M$ used to love paying for "independent" benchmarks comparing WinBlows to OSx ( I do not remember the exact one) and of course they won with out even trying... what they neglected to quote in their marketing was they had a $1M system running windows out of cache and compared it to a consumer purchasable system. Hardly a fair comparison.

One of the big truck companies got into trouble for showing an add that claimed their trucks were so much stronger than the competition by showing them being crushed as the featured truck ran over them... what they got into trouble for was that they needed to cut the uprights to achieve the effect ... at that point it became false advertising.

The point here is that you are right: manufacturers do not HIDE features. They OBSCURE them and market the obscurity. In the case of National, they are telling you all the advantages. If they told you it was simply a MPPT variant, would you pay a premium for their propitiatory system or would you shop around or even do it yourself?

I wish the peons in the general public would realize that EVERY commercial they see is there to deceive them. Sometimes it is very subtle. National markets MPPT as "Solar Magic" and QVC markets cubic zirconia as "Diamonique". Tobacco companies had to be FORCED to put the surgeon general warnings on every commercial since they spent years telling everyone in their commercials that there were no health risks to smoking, and now the drug companies have been forced to put in the audio the warnings "make sure that your doctor knows that you have impaired liver function" means the drug CAUSES liver damage...

I have customers that demand that I put 12 bit ADCs in the hardware that can only respond to 6 bits. Why? Marketing. There is no way the system can make out 8 bits, but that that extra $6 on the board price and they feel justified saying it is a 12 bit system.

Lets get off the tangent ... Oversampling, or majority voting as you seem to prefer calling it, does indeed become critical at high speeds and distances. Of course it was not an issue until relatively recently, i believe the original spec was for 9600 baud max at 20 feet max... but i do not remember for sure, only that both numbers were low by today's standards

 

[BrownOut]

What? that is 16 samples PER BIT not per BYTE... and were it per byte you would not be getting everything as there are a minimum of 10 bits per full byte(1 START, 8 DATA, 1 STOP)

No UART actually collects 16 samples per bit. That would be way, way worse than just one sample/bit.

I never said you did not get it working, I said it was not robust and would be unreliable in a noisy environment

You made lots of claims, including it doesn't operate like a real UART does, that it's marginal and theoretical, that any fool can make it work and that I do my work in my mommy's basement. Anyway, you still haven't convinced me it's not robust, or that other real UARTs are significantly more robust, except for the few that use more advanced methods.

On the contrary, manufacturers do all that they can to claim and maintain perceived superiority. A more common example would be in jewelry... QVC's "Diamonique" is just cubic zirconia and HSN's "Technibond" is just vermeil (gold plated silver)......

These are really bad examples. If a manufacturer has a product that has real superiority, then they will not hide it or obscure it with confusing tradmakring. That would only be the case only for things that in fact make the product inferior, as in your examples. For truly superior features, the manufactures and marketing departments would scream about it from every hilltop. When I worked for Integrated Device Technology co. we invented the Zero Trun-aournd Bus technology. Guess what we marketed it as: Zero Turn Around Bus technology. There world of course be no need to obscure what was a true superior technology. When I worked in telecom, we would pimp all of the features we built into our ASICS, communication standards (DOCSIS, USB, 1394, QAM, QPSK, DAVIC, etc.) There was a dizzying array of features. We also pimped every measure that made our chips less expensive, usually that meant we were consolidating functions from several chips to a single one. So the bottom line is, if someone is implementing anything that actually makes their product superior, they won't hide it, unless it's a truly proprietary method. Of course, they'll still find a way to market it.

I still say using multiple sampling/voting is more the exception rather than the rule. All of the synthesizable code I've seen so far doesn’t use it.

 

[Ubergeek63]

Actually it would be stupid for any hardware not to implement it these days ... was thinking about it this morning and it takes very little more logic than what you already have.

how about a history lesson first...

RS232 had it's "humble" beginnings running 300bps between mainframes and their peripherals, terminals, teletypes, paper tape, and modems, in a day that 1200bps ruled and 2400bps was the bleeding edge and darn close to the theoretical limit on a 3KHz voice line.

Then IBM introduce the PC that brought computing to the masses, assuming the masses could afford the $10-20K that they cost. They ran at 4MHz. The USART hardware supported 155.2Kbps but the OS did not. They knew about oversampling back then but economical logic would not handle it.

Today the least expensive logic on the market, 74HCs, clock at 40Mhz and the CPUs run in the low GHz range. Along with this we have RS232 links running at a Mbps+ and it is still no problem for cheap logic. It is for these data rates that they do indeed use it, even if they do not call it that or even bother mentioning it.

Perhaps I will sit down this weekend and puke out the code ... as to the complexity it starts with two 4 bit counters clocked off the 16x clock with the second one being gated by the incoming data. the first clears the second on overflow and clocks a shift register whose input is bit 3 of the second counter. Bit quality is also ridiculously simple: an EXOR gate on bits 2 and 3 of the second counter. A third counter tracks bit position to verify the start and stop bits. This last one could be made loadable for a programmable word length which it would normally be since the parity might not be there there and there could be 2 stop bits as well...

if you wanted you could even make it more like today's world and allow a 32 bit data frame, while incompatible with market UARTs but it would still be RS232 since RS232 does NOT specify bits per character, start/stop bits, or parity. RS232 is ONLY an electrical interface spec and nothing more.

Which brings us back to the beginning, you were in error when you titled this thread a Verilog RS232 receiver, RS232 ONLY specifies the physical layer. It has nothing to do with the data format, length or synchronization. Additionally, Verilog has nothing to do with a PHY ONLY with the data format, length or synchronization in this case.

Actually they are fair examples ... manufacturers want to market **** with out letting their customers know how pathetically simple it is to implement or how common it is in the market. I did not say they hid it, of course they market it. What I said was they make damn sure it seems like a miracle, especially when it is just a trade name for something common or simple to duplicate. National semi is an electronics example... another common man's example is the ove-glove, back when the snake oil salesman on TV were selling them for $20 each I could walk into our local restaurant supply store (not something most people have available and even many here do not know it is there) and buy them at $5 for 2. Advertising is not about telling the truth, more often than not it is about conning the consumer into buying your product.

 

[BrownOut]

Perhaps I will sit down this weekend and puke out the code ... as to the complexity it starts with two 4 bit counters clocked off the 16x clock with the second one being gated by the incoming data. the first clears the second on overflow and clocks a shift register whose input is bit 3 of the second counter. Bit quality is also ridiculously simple: an EXOR gate on bits 2 and 3 of the second counter. A third counter tracks bit position to verify the start and stop bits. This last one could be made loadable for a programmable word length which it would normally be since the parity might not be there there and there could be 2 stop bits as well...

I doubt very seriously that will work. The majority of samples will be taken past the margins of the correct, stable bit value. Early samples will be gauranteed to be incorrect, as they will be taken at the transistion of the signal. As the bit rate goes up, the signal eye gets smaller, and errors accumulate. This is the prupose of using 16x in the first place, so that the samples can be collected at the optimum point of the data interval. There is most likely dimished returns for sampling above 3 bits, as the samples move further into the margins. In this case, advanced downstream methods are most likely a better choice.

W

hich brings us back to the beginning, you were in error when you titled this thread a Verilog RS232 receiver, RS232 ONLY specifies the physical layer. It has nothing to do with the data format, length or synchronization. Additionally, Verilog has nothing to do with a PHY ONLY with the data format, length or synchronization in this case.

Fair enough. I think it's OK in literature to speak of RS232 systems though, and I am trying to help other members communicate to their boards through their computer's RS2323 ports. Though technically outside the standard, I maintain it's part of the comm system. I think you got all hung up on the post title, and didn't even bother to read the description, which better explained the project. I could have called it a UART, but someone would have griped anyway, because it's not a complete one. Do a google search for "RS232" and "verilog" and see how many hits you get. If you want to go on a crusade to make sure everyone knows the difference, better get busy

As for the marketing, I think manufactures would be running a risk of insulting engineers if they are trying to give them a tapdance. There are catchy names, like oh, I dunno 3-D Now? But they actually mean something, and engineers are prone to look under the hood. What I was saying is, for example, consider this:

Company A and B have products that are identical in operation.

Company A markets the features of it's product that reduces errors and increases it's robustness

Company B does not market those features, although they are well-known techniques not covered by patents or company secrets

Company B has put itself at a disadvantage in the market place. I just don't think they would want to do that.

 

[Ubergeek63]

I doubt very seriously that will work. The majority of samples will be taken past the margins of the correct, stable bit value. Early samples will be gauranteed to be incorrect, as they will be taken at the transistion of the signal. As the bit rate goes up, the signal eye gets smaller, and errors accumulate. This is the prupose of using 16x in the first place, so that the samples can be collected at the optimum point of the data interval. There is most likely dimished returns for sampling above 3 bits, as the samples move further into the margins. In this case, advanced downstream methods are most likely a better choice.

Actually it would work fine... the second counter simply counts when the input data is high... the end result is that bit 3 is high only when then the input is predominately high. Now my bit quality detect, on further thought, needs to take in bits 3..1 as opposed to just bits 3..2 since that leaves 8 counts out of 16 flagged as unreliable. Adding bit 2 reduces that to 4 counts out of 16 flagged as unreliable and all the while "sampling" dead center of the incoming data bit.

Fair enough. I think it's OK in literature to speak of RS232 systems though, and I am trying to help other members communicate to their boards through their computer's RS2323 ports. Though technically outside the standard, I maintain it's part of the comm system. I could have called it a UART, but someone would have griped anyway, because it's not a complete one. Do a google search for "RS232" and "verilog" and see how many hits you get. If you want to go on a crusade to make sure everyone knows the difference, better get busy

technically it IS an AR (Asynchronous Receiver), but no one would recognize "AR" as meaning anything

As for the marketing, I think manufactures would be running a risk of insulting engineers if they are trying to give them a tapdance. There are catchy names, like oh, I dunno 3-D Now? But they actually mean something, and engineers are prone to look under the hood. What I was saying is, for example, consider this:

Company A and B have products that are identical in operation.

Company A markets the features of it's product that reduces errors and increases it's robustness

Company B does not market those features, although they are well-known techniques not covered by patents or company secrets

Company B has put itself at a disadvantage in the market place. I just don't think they would want to do that.

yes but what actually happens is that company B markets the features as what they are while company A tacks on a trade name, obscuring the fact that they are indeed identical, and lies to the customer that it is better.

 

[BrownOut]

Actually it would work fine... the second counter simply counts when the input data is high... the end result is that bit 3 is high only when then the input is predominately high. Now my bit quality detect, on further thought, needs to take in bits 3..1 as opposed to just bits 3..2 since that leaves 8 counts out of 16 flagged as unreliable. Adding bit 2 reduces that to 4 counts out of 16 flagged as unreliable and all the while "sampling" dead center of the incoming data bit.

You're only counting early samples and discounting late ones. You need to decode the 16x counter to ensure the samples come from the dead center of the bit.

yes but what actually happens is that company B markets the features as what they are while company A tacks on a trade name, obscuring the fact that they are indeed identical, and lies to the customer that it is better.

In all of the presentations I've sat on over the years, I've never see that strategy work successfully. An engineer worth his salt won't fall for gimmicks.

 

[Ubergeek63]

You're only counting early samples and discounting late ones. You need to decode the 16x counter to ensure the samples come from the dead center of the bit.

I see what is confusing things... I am counting EVERY sample (the input data is the clock enable of the sample counter) and flagging the totals that are 50% +/-13% as being statistically unreliable. The end result is that the apparent sample point is dead center, but the entire bit width is taken into account. In a fault tolerant configuration if only one bit is flagged as such, and there is a parity bit, it can be corrected with 100% certainty.

In all of the presentations I've sat on over the years, I've never see that strategy work successfully. An engineer worth his salt won't fall for gimmicks.

I have known many that it would work on... a wise old prof said that it would be better to hire a "C" student than an "A" student. Working for a "C" yields a better understanding than getting an "A" does. Unfortunately, it is getting more common these days that neither is worth bothering with, more often than not basic transistor theory is not taught, it is assumed that you will not be using basic elements anymore unless you take specialized courses.

 

[BrownOut]

That's clever, but it's fraught with peril. You're sampling indeterminate data at the edges. You might think you're masking out those samples, but that depends on the "good" samples being correct, which can't be assumed in a noisy system. Better to not sample the data at the edges, as it does you no good, and can cause more havoc. Also, you can't use parity to correct bits. Parity won't report single bit errrors, only a undetermined odd numberof errors. Also, even numbers of errors aren't reported at all.

It's best to take a single or only a few samples at the optimum data point. There are much better methods of detecting and correcting data errors, in those critical situations. In all of the systems I've worked on over the years, I've never seen one that required more than a single samle.

I have known many that it would work on... a wise old prof said that it would be better to hire a "C" student than an "A" student. Working for a "C" yields a better understanding than getting an "A" does.

I wouldn't know about that. I was a "B" student, so I guess I missed out on all accounts

 

[Ubergeek63]

That's clever, but it's fraught with peril. You're sampling indeterminate data at the edges. You might think you're masking out those samples, but that depends on the "good" samples being correct, which can't be assumed in a noisy system. Better to not sample the data at the edges, as it does you no good, and can cause more havoc.

the indeterminate data would not bother it at all ... metastability, on the other hand would ... a synchronizer would have to be added to the incoming data stream to ensure there were not metastability problems...

Also, you can't use parity to correct bits. Parity won't report single bit errrors, only a undetermined odd numberof errors. Also, even numbers of errors aren't reported at all.

but that is where the bit quality comes in. If you already KNOW there is ONLY one questionable bit in the frame thanks to the sample counter, you can verify and correct it. It is not like a simple parity bit that says this frame MIGHT be corrupt. You know from the quality of the sample exactly which bits, if any, are questionable.

It's best to take a single or only a few samples at the optimum data point. There are much better methods of detecting and correcting data errors, in those critical situations. In all of the systems I've worked on over the years, I've never seen one that required more than a single samle.

well statistically it should not matter but if you insist the input data could be overrode at the beginning and end of each bit... it takes far less logic to override a couple counts at the beginning and end than it does to do math after the fact. Hence my 50+/-13% dead zone, the only thing required is to ignore the last bit for the count.

What you are missing in the data correction thought process is that locally there is a lot more information available, the hardware can tell if there is noise present or not, whereas the existing software can not. The amount of information that I have locally is double or more than what was transmitted due to my bit quality number. It is reduced to about double the data rate by the fact that I am reducing it to simply a statistical go/no go. Data wise I have 18 bits for every byte sent - 8 bits + parity as well as the quality flag for each. That allows me to reliably correct single bit errors on every byte.

In all the years that they have existed, I have never seen a DVD player that REQUIRED more than a single read of the data ... and yet 16x oversampling is the norm

I wouldn't know about that. I was a "B" student, so I guess I missed out on all accounts

LOL actually the point is more that a grade is just a number and a degree is just a piece of paper ... they only say that you have completed something and not what you are capable of. Comprehension and creativity are far more important, unfortunately personnel weenies tend to be self absorbed twits with no clue of actual company needs.

 

[BrownOut]

The indeterminate data at the edges of each bit is gonna hose the counter method if you choose to count those samples, I gaurentee that. Metastability isn't going to be your problem, rather your counter won't discriminate between vaild samples taken during the stable data interval, and invalid data taken at the edges where the signal is in transition. Synchronizers won't help the situation at all. Even if you come up with a better scheme, you sill cannot gaurentee you'll only have good or damaged bits. Multiple samples can only mitigate the corruption effects of noise, not eliminate it. So, no correction method using the parity bit will be 100% effective. If data delivery is that critical, I would opt for proven methods that greatly diminish the chance of bad transmissions.

16X oversampling in DVD's does not reduce errors. It's not comparable to serial communication. It's a whole different function involving restoring inter-sample information, or really faking data, and not applicable to serial data in any way.

 

[Ubergeek63]

The indeterminate data at the edges of each bit is gonna hose the counter method if you choose to count those samples, I gaurentee that. Metastability isn't going to be your problem, rather your counter won't discriminate between vaild samples taken during the stable data interval, and invalid data taken at the edges where the signal is in transition. Synchronizers won't help the situation at all. Even if you come up with a better scheme, you sill cannot gaurentee you'll only have good or damaged bits. Multiple samples can only mitigate the corruption effects of noise, not eliminate it. So, no correction method using the parity bit will be 100% effective. If data delivery is that critical, I would opt for proven methods that greatly diminish the chance of bad transmissions.

16X oversampling in DVD's does not reduce errors. It's not comparable to serial communication. It's a whole different function involving restoring inter-sample information, or really faking data, and not applicable to serial data in any way.

It actually does a little of both but you are right in that the serial data is not repeatable... In fact the old transfer protocols and even the modems would request retransmission of bad packets. Synchronizers are only effective at higher data rates... Actually I expected the indeterminate data at the edges to come through, the only thing that would "break" it would be the eye diminishing to the point that it was over 50% noise.

I never said i could guarantee it... what i said is that I could determine "bit quality", the likelihood that the bits are good. If there is only one bit that is likely to be bad in the frame (byte including parity), then you can reliably correct that one bit. in the case of a high speed error corrected link the result is fewer requests to resend the faulty data.

these days at common serial data rates metastability is not a problem, it is typically 3-5x the period of the flip-flop clocking frequency but I have seen it as much as 10x. in an FPGA with a 300MHz F/F clocking rate that makes the switch point unknown between when you expect it and 33nS later, obviously a bigger problem at the 74HC frequencies of around 40MHz. In a single center sample system that means at a bit rate of 2MHz a noise pulse could trigger metastability that might not stabilize until the next bit comes in.

it is certainly easy enough to dump the first and and last couple samples... but i still do not think it is necessary since they will be swamped out be the real data. That is the nice thing about a statistical mean, the farther away from 50% the greater the PROBABILITY that you have good data. Hence flagging data CLOSE to 50% as being unreliable. If only one bit in a byte is flagged you can indeed verify it...