Re: Coding style, wait statement, sensitivity list and synthesis.

Hi Jim, Happy New Year !

A few more notes below.

Rob

"Jim Lewis" <Jim@xxxxxxxxxxxxxx> wrote in message news:11r97679jmsap7b@xxxxxxxxxxxxxxxxxxxxx
> Rob,
>> Well, if there were synthesizable descriptions for these (which there are not),
>> or 1076.6 would define this Xilinx intended hardware should be synthesized (which is
>> does not, since it defines that the second clock should be ignored), then we would at
>> least assume that XST supports this style and create this hardware. But it does not :
>> ERROR:Xst:827 - dual_edge.vhd line 12: Signal Q cannot be synthesized, bad synchronous description.
>>
>> I think XST (and all other synthesis tools) are right and 1076.6 is wrong.
>> So none of the assumptions you are making seemed to be holding.
>
> The intent of the 1076.6 is that it creates a double edge register.
> I understand this because I was part of the committee and attended
> the meetings.

I already thought your name looked familiar. We might have met at
one of the meetings. I was also part of the 1076.6 committee, at least
in the early days, when we were still talking about the numeric_std/bit packages.
I even wrote the original (magnitude/equal) comparator functions
for these packages, but that was about the last I did for 1076.6.

> Unfortunately now we have obviously confused at least
> one of the implementers and this is a situation we need to correct.
>

It that was the real intent, then I think you confused more than one
implementer. Or they decided collectively not to implement the
double-edge hardware feature to was that 1076.6 recommended it.
I don't know of any synthesis tool that accepts this style and creates
a double-edge sensitive register.

>
>>> 3: "The signal in the first clock edge expression
>>> (textually) shall be taken as the functional clock."
>>>
>>>If there is a precedence relationship in the target hardware,
>>>then the higher precedence clock must be coded first.
>>>
>>
>>
>> Right, and the other clocks should be ignored if you read the other text :
>> "The signal in the first clock edge expression (textually) shall be taken as the functional clock".
>>
>> Which is my point exactly.
>
> First to understand what is being said here, you have to
> re-read the previous points and understand that each clock
> contributes to the hardware creation.

Additional confusion is in the note(2) :

"The determination of the functional clock is made on a process-by-process basis;
the intended functional clock has to be coded first in each process."

There is hardly any other way to interpret that than to assume that
there is only one clock per process, and also that is that clock
is the first one in any (mutually exclusive) if conditions.

>
> As I read this statement, I can see why it troubles it,
> however, we did not get any corrective action relative to
> it during balloting. It is hard to identify these issues
> myself as I know the intent, so it is not confusing to me.
>
> The statement that troubles you refers to ASIC hardware where
> there are two clocks: one is a functional clock and one is a
> scan clock. In this case, there is a priority relationship
> in the hardware.

I vaguely remember that in 1076.6 early days, we talked about
modeling the IBM style separate master-slave register hardware,
which also allowed some pretty exotic scan/functional clock designs.
But I do not remember any talk about double-edge sensitive registers.

>
> The assumptions in 1076.6-2004 about multiple edge register
> coding states that the clocks are mutually exclusive.
> This governs the coding style. Hence what the statement is
> intended to say is that if the code is mapped to hardware
> that has precedence in it, give the first clock in the code
> the highest precedence in the implementation. By requiring
> something specific, it gives the user the most control over
> the resulting implementation.

Understood. I think the text fucusses way too much on this assumption
(of mutual exclusive clocks) and misses the point : that double-edge
sensitive registers are allowed to be synthesized.

Now there is still major confusion with the 1076.6 text regarding
this coding style :

process (reset, clk1, clk2) begin
if (reset) then
Q1 <= '0' ;
Q2 <= '0' ;
elsif rising_edge(clk1) then
Q1 <= data1 ;
elsif rising_edge(clk2) then
Q2 <= data2 ;
end if ;
end


Where does it state that this is a process with two clocks, which should
synthesize to two separate (single-edge) DFFs ?

>
> For the case where the hardware implementation has mutually
> exclusive clocks, this statement does not apply

The 'mutually exclusiveness' of the clocks is a minor issue
The text I miss very much is :

"Each assigned signal in a process should be clocked to at one and only edge to be synthesized to a regular DFF".

possibly extended with :

If a signal is sensitive to multiple edges, a multiple-edge hardware element should be synthesized.
If a signal is sensitive to no edges (only to combinational signal events), then no edge-sensitive hardware
should be synthesized.


>
>>>>Just stick with a single clock per process, since that is supported by every vendor,
>>>>prevents any simulation-synthesis mismatch and does not violate any 1076.6 rules.
>>>
>>>And if we do this, how do you propose that we code
>>>the Xilinx hardware referenced above?
>>
>>
>> Only a simulatable model can be written.
>> And that is what Xilinx intended also (that is why thei made these models instantiatable).
> I think I remember seeing that Xilinx had a coding
> style for this using shared variables.

Do you have an example of that that XST accepts ?
And does this match the style proposed in 1076.6 ?

>
> Instantiation and/or non-portable code is a great solution
> from a FPGA-Vendor perspective as once you use this part,
> you are stuck with them. This is not so good for users.
>
> Is instantation your best proposal?

For these very rare dual-edge sensitive register, yes, I think instantiation
is probably the best (safest) solution. Couple of reasons :

(1) Dual-(or multi-)edge sensitive register elements is not common practice in hardware design.
Many technologies will NOT have general purpose multi-edge sensitive registers.
So writing HDL in such form will already restrict the target technology you can map too.

(2) Many RTL designers are novice. Opening them up to dual-edge sensitive hardware
design is like opening a can of worms. If you accept HDL coding style that models
exotic hardware behavior, many RTL designs will start to contain it. And this makes
HDL coding technology dependent (see reason (1)) and in general makes RTL models
harder to understand, and possibly riskier: Many company RTL design rules include
single-edge sensitive design only. How can we protect such rules if 1076.6 opens the
lid of the vast number of designs possible with multiple edges ?

(3) So much for synthesis creating a dual/multi-edge hardware primitive.
How about timing analyzers, equivalence-checkers, model-checkers, test pattern generators,
hardware accellerators, and a whole spectrum of other tools.
Are they supposed to all of a sudden deal with multi-edge sensitive hardware elements ?
I do not think the EDA market is ready for that.


>
> I would suggest that you understand the coding style
> put forward by 1076.6-2004 as a multi-edge storage
> device and lets get the wording you object to fixed so
> all can understand the intent of the standard.

I would suggest to clarify that there is only one edge allowed per assigned signal :
(1) Each assigned signal in a process should be clocked to one and only edge to be synthesized to a regular DFF.
(2) It is an error if a signal depends on two independent clock edges.

Anything short of that is opening up a can of worms.

My 2 cts.

>
> Although this is a non-offical interpretation of the
> standard, it is unlikely you will hear anything in
> official interpretation.
>

I know. It takes a long time to get commitee approval.
But is takes probably more efford to convince implementers and the design community
if you try to standardize something that has the risk of creating more problems that it solves.


> Best Regards,
> Jim
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Jim Lewis
> Director of Training mailto:Jim@xxxxxxxxxxxxxx
> SynthWorks Design Inc. http://www.SynthWorks.com
> 1-503-590-4787
>
> Expert VHDL Training for Hardware Design and Verification
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


.

Relevant Pages

  • Re: Coding style, wait statement, sensitivity list and synthesis.
    ... Or they decided collectively not to implement the double-edge hardware feature to was that 1076.6 recommended it. ... there is a standard for coding styles? ... modeling the IBM style separate master-slave register hardware, which also allowed some pretty exotic scan/functional clock designs. ... In a design review, I require all multiple clock and clock ...
    (comp.lang.vhdl)
  • Re: Security and EOL issues
    ... OS software resources are designed that reserved ram and disk space among other resources, to reflect what current hardware size is available. ... (There was a security patch a few years ago that could not be applied to NT4 as it required more resources then NT4 could provide. ... Installing air bags requires that the automobile manufacturer design, test, ... Computer Emergency Response Teams, and Digital Investigations. ...
    (Security-Basics)
  • Re: [PATCH 06/23 -v8] handle accurate time keeping over long delays
    ... which is the same as the underlying hardware counter. ... So you are saying that you can trivally make it work with a clock that is, ... will never change while I am in the preempt disabled code. ... it's called from an IPI running on each CPU. ...
    (Linux-Kernel)
  • Staff HW Engineer ~ Lead Us to ATCA & Beyond in Your End-to-End Board-Level HW Desig
    ... The senior level hardware engineer looking for the product realization ... and true ownership that comes with full end-to-end board-level hardware ... help us retain dominance in the design of high performance switching ...
    (comp.arch.embedded)
  • Re: 10khz DBSK decoder
    ... In an AVR, you may want to come closer to the 'hardwareish' thing: run the whole thing as a Costas loop or as a signal-square-and-PLL, and do integrate-and-dump. ... In retrospect, the ISR should have just taken ADC samples and shoved them into a queue, then set a flag. ... But I had never seen that design pattern, so it just ran with that big bloated ISR... ... You'll get more consistent timing if you can trigger your ADC from hardware and interrupt on the end of conversion pulse. ...
    (comp.dsp)