Can I use Verilog or SystemVerilog to write a state machine with clock gating function?

e:

line is accessed at a time. So the cache is designed as a RAM with data, t ags, and state. Each cycle the data, tags and state are read, and a single state machine is used to generate the next state, which is written back int o the RAM.

new data is different from the present state, and uses that to generate a clock pulse only if necessary.

LOL! So can you share your secret comparison using no gates?

Rick C.

--- Get 6 months of free supercharging --- Tesla referral code -

formatting link

Reply to
gnuarm.deletethisbit
Loading thread data ...

My terminology divided Synchronous (transitions happening on the edge of some 'global' clock) vs Asynchronous, where some device changes its state independant of the main clocks, perhaps with an asynchronous set/clear or being clocks by some input signal that isn't considered a system clock.

Synchronous system can be divided into single domain and multi-clock domain systems, for which you seem to want to define 'Synchronous' as what I would consider 'Single Clock-Domain Synchronous'. Multi-clock domain synchronous system tend to not be define as *A* FSM, but can be as a set of FSMs that interact.

Proper multi-clock domain systems need a bit of care at the domain boarders to avoid meta-stability issues, but this isn't really that hard to handle.

Reply to
Richard Damon

.. snip

what?

the opposite, it is really hard to handle unless you have a single signal moving from a slow to fast clock domain. Why do you think there are so many (quite expensive) CDC tools (Bluepearl, Spyglass, Questa CDC, Conformal, Meridian, ..) Have a look at past ASIC user surveys (like Wilson research group) and you will find that CDC errors are the number 2(!) reason for a respin, I would say that qualifies as a hard to handle issue given the cost of a respin nowadays.

Trying to a find a deep convergence, reset or a CDC glitch problem in a

30 clock domain design (not that unique) is not for the faint-hearted and that is after identifying that it/they exists in the first place (simulation won't show you unless you use CDC-FF models from your CDC tool).

Time to power cycle my TV box again as it got stuck yet again....;-)

Hans

formatting link

Reply to
HT-Lab

To be clear here - my definition of a "state machine" matches what I'm sure most of the other poster's here define it as. A small (less than

5-6 bits) number of states, operating on a single clock domain. Small enough such that a Synthesis Tools can apply a model to, where as the "state labels" can be disassociated from the actual bit encodings (and number of bits). Such a tool can then re-encode these bit encondings (and number of bits) in order to optimize the circuit, balancing such metrics as power, timing, area, soft-fault tolerance, and errant state detection. Such a re-encoding would preserve all state transitions, and output products - but change the underlying bit-encodings.

Anything more than 5-6 bits (I don't think I've ever designed any with more than 4) would call (in my opinion) for some re-partitioning and redesign. In fact, I'd wouldn't be surprised that even with todays modern tools, a FSM optimizer would start choking when you reach 8-10 bits.

Now, again this is all just a MODEL that we can apply as people to a digital, synchronous, single-clock domain circuit.

Weng seems to be applying a looser definition of "state machine" that he's applying to model a CPU Cache circuit (with a ginormous number of states, or perhaps a ginoromous number of small, indepenent state machines all interacting). That's fine to model it as such, if there's some sort of benefit to having this model. (I think it's a silly model to make, without any benefit, but *shrug*)

My only argument, which I still don't think he understands, is with his loose of a definition, one can apply his "state machine" model to ANY digital single-clock domain synchronous circuit. (I just wanted to avoid that last mouthful and just say "synchronous".)

Weng further goes on and says, with this "state machine" model of a CPU cache, he can now apply some secret algorithm to optimize something. My (and other's) points here were that if his algorthim when applied under his "state machine" model for a CPU cache, would also apply to ANY other digital single-clock domain synchronous circuit.

Many then would point out, that this would then all fit well within established prior art. Transformations of Clock Enable circuits to Gated Clocks are well understood to both the tools and designers. As per normal, the devil is all in the details of the cost/benefit metrics of making such transformations.

(And also pointing out, I'm completely unclear as to what Weng's super snazzy algorithm is, under what conditions it could work, what it's cost could be, etc.) Some of his post seems to talk about low power and magic clock gating, but none of it is very clear.)

Regards,

Mark

Reply to
gtwrek

n
f
d

l).

A customer asked me how I handle multiple clock domains and I told him that unless there was reason to perform significant processing in multiple cloc k domains I transition all I/Os to a single clock domain as quickly as poss ible so that all interaction between circuits are then in that one clock do main. The resulting domain transitions are limited and well defined making them easy to debug.

Rick C.

--+ Get 6 months of free supercharging --+ Tesla referral code -

formatting link

Reply to
gnuarm.deletethisbit

Solving clock domains issues is fairly straight forward when they are identified at design time. You do need different strategies depending on the basic case you are working in, is it a single signal, or is it a bus, are we going fast to slow and need to make sure the signal gets across, etc. What is hard is to verify that you have detected all the cross domain transitions and performed the needed mitigations for it. They can also get harder if you are trying to squeeze every last drop of performance out of a cross domain connection.

I suppose some things get mentally hard to shake, like making the assumption that your synchronous clear terminates simultaneously in all domains (instead of the idea that simultaneity isn't really a concept in a multi-clock domain system.)

The other issue is that when you start to move to higher level abstractions the real RTL code, it becomes easier to miss the cross clock domain transfers or to miss some of the interactions between multiple instances of a given cross-domain transfer (Two signals that are together in clock domain 1 will not necessarily be together in clock domain 2 after transitioning, unless care is taken to keep them together).

Reply to
Richard Damon

This seems to be par for the course with patent seeking. The typical paten t seeker is not proficient or even familiar with a given area of expertise, has ill-conceived ideas of what the tools can do or how the tools work and proposes poor solutions to issues no one else sees as problems.

I would be interested in learning of such a patent seeker's background and what sorts of work they have done in the past.

Rick C.

-+- Get 6 months of free supercharging -+- Tesla referral code -

formatting link

Reply to
gnuarm.deletethisbit

Hi Mark,

Is there anywhere I said that "Weng seems to be applying a looser definition of "state machine" that he's applying to model a CPU Cache circuit (with a ginormous number of states, or perhaps a ginoromous number of small, indepenent state machines all interacting)."

I only said that one L2 cache line has a state machine, and 6M L2 cache would need 100,000 state machines.

And snipped-for-privacy@gmail.com resolved my problem accurately and excellently.

Invincible! Marvelous! Smartest!

Thank you, snipped-for-privacy@gmail.com.

Weng

Reply to
Weng Tianxiang

The basic concept of a state machine is that given a state variable S (implemented with some number of bits and representing states like S0, S1, S2, ... Sn), and a set of inputs I, then we can say that we have the logic that at the clock signal

S
Reply to
Richard Damon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.