Coloring by clock?

I'm getting tired of poring over my code to find asynchronous inputs to my state machines that make them go "zero hot."

Has anyone seen a context sensitive editor that would let me color my signals by the clocked process that created them? I guess another way to help in this endeavor would be a syntax checker that warns of inputs to state machines that are not synchronous to the same clock. Does that exist?

regards, Gabor

Reply to
Gabor
Loading thread data ...

Another way is to use only clocked processes and to synchronize the inputs that need it.

-- Mike Treseler

Reply to
Mike Treseler

The point is to find the "inputs that need it" without going crazy in a large design...

Reply to
Gabor

I would agree. Most recent FPGA families you get I/O registers generally for free and generally not much use for anything else. In some families you can even have 2 flip-flops in the I/O, potentially on different clocks, like in Spartan-3. You probably use far more resource using grey encoding, or some other handling scheme, than just registering the signals as they come into the FPGA.

John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board.

formatting link

Reply to
John Adair

Hi Gabor, As a born-again member of the Church of Synchronology, I would question your design philosophy. The bible of Synchronology, the inspired word of the supreme being Xtal, says thus:-

Yeah, thou shalt synchronise everything to a masterclock on the way in to the FPGA to make new signals in a single clock domain (Genesis). Clock all your machines with this masterclock (Job). Retime stuff as needed on the way out of the FPGA (Exodus). More work up front, but I'll finish long before you, (Proverbs) and have a much more robust and reusable design, with easy constraints generation (Numbers) as you're now finding out. (Lamentations) Cheers, Syms.

Reply to
Symon

[..]

But is also written what to do if timing constraint meets power constraints?

I like to have each design synchronous. And actually doing a _synchronous_ ASIC using several different clocks runing on various frequencies, but this is nearly impossible if it comes to do a prototype with an fpga and would be complete impossible if the design would need to hit the edge of technology, as often seen when doing high speed data processing.

bye Thomas

Reply to
Thomas Stanka

The inputs that need it are device pins driven by logic not synchronous to the fpga clock. No need to pore over your code.

-- Mike Treseler

Reply to
Mike Treseler

Hi Thomas, Ah, but this isn't comp.arch.asic. Those heretics have their own book! They need to as they don't get FFs with CE for (kind of) free like we do in FPGAs. But, point taken! Thanks, Syms.

Reply to
Symon

Hi,

Sym> >

design

[..]

book! They

in

Well, some designs are pure Fpga designs never intended to target an ASIC and some ASICs never have to be implemented on a FPGA. An Asic has IMHO better possibilities for clock gating than an Fpga, so the point with different clock frequencys for power purpose will mostly imply asynchronous clock domains and there a violation of your synchronity rule :). I don't know which technology provides FF with CE, but there are more than Virtex-4 devices out there in the world *g*.

bye Thomas

Reply to
usenet_10

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.