TonyM

Please edit your question to show your current circuit. If your circuit outputs your PWM waveform through a D-type Flip-Flop (DFF), all clocked by a crystal oscillator in a circuit with good layout (not a breadboard of long wires), then you will get very low jitter. If you take it from a comparator output then not. It would be straightforward to do in a CPLD if you know how to design the firmware, there's cheap 'chewing gum stick' sized boards out there that'll hold everything and free development software. Starting point here is: show your circuit in your question, plus how it's put together.

@CarlRutschow, "It would appear to be very difficult to do that all digitally without using a micro" Straightforward to do it with a CPLD/FPGA.

This was usually pronounced "two pounds three and fourpence" Actually, it was more typically "two pound three and fourpence". But saying "shillings" was dropped for the normal reason: it's two awkward syllables that aren't needed. That's colloquial speaking for you. If you're saying it twenty times a day, or 500 times a day for a shopkeeper or market trader, you naturally drop words that every knows to save time and for better flow.

@SparkyNZ, sounds like more aggro than anyone needs, glad you got it fixed. So is it all stable and working now? I have to say that the video stuff sounded on shaky ground but you've obviously got stuff looking good on the screen so it can't be.

@SparkyNZ, are you saying you've fixed the problem now and it's all gone away?

So @MatthewHenderson, the question to yourself really is: can you design a simple mechanical system to accommodate an optical encoder or Hall Effect sensor. Reason is that they're the industry-standard cheap and reliable speed detection systems, so you can't be designing a system that eliminates their use.

Yes, building on @MarcusMüller good points, it does read like you're hoping there's some amazing method outside of the two standards (Hall Effect, optical) while being cheap. And there aren't. So I think you've got to re-engineer what you're trying to make to accommodate a standard method.

A very warm welcome to the site :-) (a) Why are optical sensors out? (b) Please edit new info (like this and your comment on Hall effect sensors) into your question, don't add it in comments. Otherwise, readers have to piece together the actual question from scattered fragments. Comments can be deleted over time by mods. Thanks.

Why not forget any the more-rep-means-you're-better rubbish and simply advocate being friendly and assuming the best with others in a disagreement, whatever they respond with. It's only a website with some made-up rep system, it's not real life. Surely a 'Be Nice' approach is easier on all of us.

Also, your rep-means-status thing suggests that you would immediately defer and give way to another user with much higher rep in a disagreement, as they 'outrank you' in your logic. Which I'm sure you know you wouldn't.

Using this illogical rep-gives-status logic, as you've posted 50 questions to another user's 1 question then that suggests you know 50 times less than them. Surely you should follow their lead as they know more.

Helpfulness is not just limited to handing out info. It's about dealing well with others in disagreements and it's far more valuable there and costs nothing to deploy, whether it's reciprocated or not.

"heavily criticising my question". Hardly, one would have to be far too super-sensitive to discuss on Q&A sites to call that 'heavy criticism'.

@cjs, been busy. It's disagreed, not 'quibbling' (a word usually used to be derogatory).

"I suggest you consider carefully the advice you give to people with more than twenty times your reputation" Site guidelines see all users equal and should get fair treatment from each other. (I'd be tragic if I looked down on people because of some numbers on a website.) From your statement, does more rep mean a more important user, more worthy than lesser people with their lesser rep? From your later comment, does lower rep mean users who don't know as much as higher-rep and should never question them? Do users show true helpfulness by resolving disagreements graciously, talking as equals?

You brought it up, so others reasonably commented. But no, it doesn't indicate or mean a single thing except, it appears, to yourself. On this particular site, upvotes are commonplace for anything. People are so kind and upvote users work a lot. But you could have 5 billion rep and from that you'd be expected, more than anyone, to deal the better than anyone with disagreements with others. The site policy: Be Nice underlies everything. Be great if you valued that instead of (apparently) rep. I don't think you'll ever retract a point but I wish you'd take a breath and reconsider what helps.

"I suggest you consider carefully the advice you give to people with more than twenty times your reputation" No-one else is seen endorsing the idea that more rep means cleverer/wiser. The site guidelines certainly don't. Higher reputation simply just someone spending a lot more time posting, especially here where rep points rack up easily. Far from a wisdom measurement, users should see higher rep to mean better behaved, leading by example on Be Nice/CoC policy ("we expect all users to treat one another with kindness and respect").

@Tyassin, are you up with the last part?

@Tyassin, so that's something your circuit doesn't have: input noise filtering and metastability rejection. All OK with that, make sense?

All internal logic uses the DFF_Q level as the input level. So the input has to be steady for 3 clocks before it is accepted for use internally.

It uses five DFFs. The input pin goes to DFF1_D. DFF1, DFF2, DFF3 and DFF4 are connected in series as a shift register, so they shift in the pin level. When DFF2_Q, DFF3_Q and DFF4_Q are the same (000 or 111), the DFF_Q level is clocked into DFF5.

It's simple but I prefer an input circuit that is much more reliable and also rejects high-frequency noise. I've used it in all FPGAs since the start and its helped produce rock solid FPGAs.

One way of doing this is to pass each input through two DFFs in series, DFF1 and DFF2. If DFF1_Q goes metastable, it won't be sampled by DFF2 on DFF2_D for another clock. By then, DFF1_Q will have headed towards a better logic LOW or logic HIGH voltage and DFF2 will turn that into a good logic voltage. Internal circuitry just connects to DFF2_Q.

So any input going into the FPGA that's not related to the clock (most/all inputs) can/will cause metastability in the input DFFs. It must pass through an input circuit that prevents metastable DFF outputs driving wrong (e.g. half-VDD) voltages into the circuit and making it misbehave and fall over.

Great, just doing one step at a time and all that :-)

Can you see the problem?

Here, the inputs from the outside world don't have a source clock, they're just changing at some random time wrt to the destination clock (here, the FPGA logic clock).

That's a common problem with synchronous digital logic circuits: clock domain crossing. Bringing something changing from one clock into logic clocked by another clock.

@Tyassin, so when inputs from switches, sensors and anything else truly asynchronous, are brought into a synchronous digital logic circuit (i.e. one with clocked DFFs) then that input can cause metastability. That's if it (a) goes into a DFF_D input and changes just as the DFF's being clocked or (b) goes into combinatorial logic that feeds a DFF and, again, causes the DFF_D input to change just as the DFF's being clocked.

That make sense?

Metastability shows what an analogue flip-flop circuit will do when operated outside of its parameters for reliability.

Logic gates are analogue circuits that can be viewed as digital to simplify dealing with them and make its designers more productive, able to produce bigger circuits more quickly and reliably.

This highlights a golden principle: Digital circuitry is simply convenient analogue circuitry.

@Tyassin, OK, there's a few there so I'll do them one by one :-)

@Dillon, glad you got it sorted :-) I'd posted above "you fix it by good grounding" and that was the problem, from what you've said. I'd asked for a diagram and I think drawing one would have helped you see the problems with the grounding. Worth bearing in mind for next time: a clear view of things makes everything a lot easier. Good luck with the rest of the project.

@NickAlexeev, as said I prefer separate chat rooms with each different person or few people for that one subject, ending when it's done, rather than one for everything with the same group like a forum. I'm glad you've found what you like there, different people like different things. Have a chilled evening.

As an aside, from looking at the mostly 2-user rooms on the site I think my case is the case for most people, they're looking for what I am too. Any road up, easy enough to keep one alive like this one :-)

@NickAlexeev, but the appeal of the chat room to me is a direct and uncluttered conversation with just an OP, where you can get lots done. That's the not what more populated chat rooms are, where it can get pulled around in a multi-way talk. There's pros and cons of the fuller rooms, and people might like just the multi-way talks, but it's the opposite of what I'd come to chat for.

Best of luck with it, @Dillon, and do let us know. Chatrooms die and can't be posted to after, I think, a week's inactivity so drop in and post something to keep it alive along the way.

Hi @SparkyNZ, so did ModelSim solve the whole problem for you or just part of it?

In fw (HDL) development, it's totally different and it's really a must and such a rewarding must. It's far, far faster for debugging that using SignalTap etc. and far more productive. I'm usually on the simulator for 70..80% of development time, only going to the target device when I'm very confident it'll work. Always paid dividends doing it that way.

In sw, it's a nice-to-have that's so often surpassed by using a debugger on the sw in the real system.

On ModelSim/Questa/othersims: in my experience, there's a world of difference between simulation for software development and simulation for firmware development.

@SparkyNZ, wade into VHDL, it's a thing of beauty :-)