Strange "Style guide" requirements...

It makes synchronization easier to design and test. I take this one step further and use one process per entity and one clock per process.

You have the option of writing and testing a version in your own style, then using the same testbench on a restyled version.

I would cover this requirement with Fmax on a synchronous design. This covers all internal paths.

-- Mike Treseler

One could rant for hours about #1, and all sorts of similar things that may be done with the idea of supporting design reuse, maintainability, lowest-common-denominator quality, ... but I shall refrain.

In regards to #2: I think it's a good idea. However, what does the statement mean? I think the case of static control signals could be covered by an explicit multi-cycle constraint or TIG. Then, the exceptions to the global clocking constraints are documented. Clock-domain crossings need to be managed in the design architecture, and most likely at the constraint level. Leaving those constraints out may result in a working design, but sometimes the tools just do the unexpected--really badly.

In the distant past, I found I got better results (successful timing closure w/ a working design) by purposely NOT constraining certain paths, but instead using location constraints to put the source and destination points next to each other. Since that time, the tools & constraint defintions gave gotten much better (but manual placement still helps on critical paths.)

JTW

"Nial Stewart" wrote in message news: snipped-for-privacy@mid.individual.net...

Agreed. I normally find myself fighting against the opposite problem - people with a very hardware-ish mindset writing one process for each tiny little bit of functionality "to make it easy to understand" (which, of course, it doesn't; that's like saying you can most easily understand the schematic of a big CPU if it's all drawn as NAND gates). But your rule is bizarre and utterly unnecessary.

It's also plain flat-out wrong, if you have a design in which some of the registers have asynch resets and some don't; using the traditional form of synchronous process, you need two different processes for the two sets of registers (though we have discussed alternatives here, in the past).

If this is VHDL we're talking about, processes offer a very important packaging/data-hiding construct, the variable. Enforcing that the whole architecture be in one process means that you can't have individual chunks of functionality hide their inner workings from others. Silly.

I absolutely agree that it's a smart move to keep the number of processes reasonably small (and, of course, Mike Treseler would be even more emphatic about that). But to suggest that there should be only one per clock is truly nonsensical. What rationale is given for that rule?

Absolutely agreed.

Just a thought (thanks Mike):

process (clock) begin if rising_edge(clock) then low_level_control_procedure(...); protocol_procedure(...); end if; end process;

Only one process, with two bodies coded in two procedures. You might - just might - get away with that....

Does this truly mean "no unconstrained paths", or does it mean "no path without its own explicit constraint"? You could quite reasonably argue that a simple frequency constraint on each clock in the design is sufficient to constrain every path in the design. If the customer is indeed asking for an explicit constraint on every path, then you should point out the exceedingly large increase in your fees that will be called for if you are to maintain the constraints across all future changes of register size, name and so forth. Mutter darkly about wanting to insert a few extra pipeline stages. Pace up and down the room in an agitated manner discussing (to yourself, of course) the finer points of synthesis name rewriting rules. Calculate the expected cost of rewriting all the constraints if the customer migrates his synthesis to a different tool.

This requirement sounds to me like a mangled and misunderstood reworking of something more sensible such as "every I/O pad must have an appropriate setup/hold or output-delay constraint".

I suspect that oddities rather come with the territory when you're working as a contractor. Like the design I had to rework a few years back, which had started life as a schematic and caused Quartus to report something like 130 different clocks...

Good luck.

Hello Jonathan, Yes, I break this guideline sometimes to infer a blockram process, but I have yet to come across any other reason to exclude resets for an FPGA design process. They make simulation easier and they are free.

It also forces the designer to use variables as registers, which is why I was amazed that anyone other than I would consider such a guideline. It is more likely that the customer does not understand its implications.

Whether it is silly or not depends on the designer's relationship with wires. I prefer to let synthesis infer most of these inside the design entity/process and keep all the explicit signal declarations in the top structural entity for wiring ports. An entity/process hides variables just as well as a process does.

I agree that this is a matter of style. If you don't mind declaring and hooking up your own wires between processes -- go for it.

You certainly can for non-synopsys synthesis. I don't know for sure that synopsys still has a problem with procedures because I haven't had a volunteer to synthesize my reference design on synopsys for more that three years.

I'll bet that was redo ;)

-- Mike Treseler

Whoops. No it doesn't. Consider this statement retracted.

-- Mike Treseler

I didn't mean "you can make it work" - I'm pretty sure DC and all the other realistic synth tools can handle procedures today, provided they make sense as the body of an RTL process. What I meant was that if the customer is so dopey as to impose a rule like that, they're also probably too dopey to notice you weaseling your way around their idiot rule by writing a bunch of procedures.

This is a perfect cue for the embarrassing moment when Nial points out that his client got their style guidance from us..... nah, just kidding (I hope) :-)

Craziness! This probably descibes my coding style early-on, when I didn't have much experience. But after reading many more examples (in both Verilog and VHDL) and via my own experiences I've found that using multiple processes with the same clock within the same entity - done properly - vastly improves readability, comprehension and maintenance.

Of course as always there's a trade-off, and you have to decide when to use multiple processes, when to instantiate sub-entities etc etc, but an example I commonly use it to implement registers in one process, and other functionality in another.

I'm actually starting to use blocks more often now, to avoid long lists of signals in the entity declaration that are hard to find in the code. If there's a functional block that I don't want to instantiate as another nested entity, I'll use a block and define any local signals that have no scope outside the function.

I guess I should also mention that my original background is software, so perhaps I'm coming in with a different mind-set.

Feel free to disagree, but I doubt you'll change my mind. I've seen enough code now (good and bad) to know what I do and don't like... ;)

Regards,

An alternative is to use variable data structures each with a per-tick update procedure.

My original background is hardware, but I have grown fond of vhdl functions, procedures and structured variables. You never know what someone is going to like ;)

I guess I prefer full structural or full procedural. I'll take an instance over a block. But don't change your mind on my account. I think Andy would back you up.

-- Mike Treseler

The explanation was that it was to cut down the mistakes made with clock enables!

No unconstrained paths. From memory in ISE there's an output at the end of the run which tells you how many paths are unconstrained. This had to read 0.

This company is a big 'household' name and I have a lot of respect for the engineers there, they were good guys.

I just didn't understand these two mad rules.

I had one where the FPGA built with ripple clocks everywhere with a reported maximum speed of 28MHz odd. They were clocking it at 50 MHz.

That too was a start from scratch re-design.

:-(

Nial.

No, they had generated this themselves.

It was generally very good, they had taken a good look at how best to structure design directories for clarity and re-use, used source control etc. It was just these two odd rules I didn't agree with.

Nial.

I guess a few simple follow up questions back to people at that company (if that's possible) then would be:

1. What types of mistakes get made with 'clock enables'?
2. Are they seeing fewer of these mistakes of those types since instituting the "Only one process per clock is allowed per entity" rule?

But I guess it could go on endlessly trying to fathom the rationale without direct access to the rule maker and the reasoning that went into it.

Kevin Jennings