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


"Jim Lewis" <Jim@xxxxxxxxxxxxxx> wrote in message news:11rp67u9f36u8ba@xxxxxxxxxxxxxxxxxxxxx
> Rob,
>> One thing we (implementers) all have seemed to agree on is that the
>> hardware elements we synthesize have one DFF style : the one with
>> a single-edge.
> Well then ya-all just need to get with it.
>

See below: So it is a 'target technology' issue, and anyone using it will
be writing technology-dependent HDL code.
At least with technology-specific instantiation you know exactly what you get...

>
>>>Add to that the confusion of finding a standard on IEEE's
>>>webpage. Took me a couple of tries to find it because I
>>>went to the subscription page rather than the standards
>>>page. I have the advantage in that I know it is there.
>>>
>>
>>
>> I totally agree. 1076.6 should be freely available and a URL click away.
>
> I was saying easy to find. I didn't say free.
> Someone needs to fund some part of IEEE standards.
> Although IEEE includes standards in their core values,
> they do not fund standards in any way. Caution, this is
> one of my hot buttons - in the US they fund IEEE USA (a
> lobbying organization) but they don't fund standards.
>

We should drink a beer over this some day..

>
>> But, purely anecdotal, let me give you one of our 'open' bug-reports.
>> There is this guy who wants us to synthesize a flip-flop from this :
>>
>> subtype TWOBIT is a std_logic_vector(0 to 1) ;
>>
>> process(CP, Q, D)
>> begin
>> case TWOBIT'(CP'last_value & CP) is
>> when "01" => Q <= D;
>> when others => Q <= Q;
>> end case;
>> end process;
>>
>> It behaves as a flip-flop !
>> Now, 1076.6 or not, what do we do with this customer request ?
>
> You should hire me as a consultant. :)
> The simulation semantics say it is a latch. D is on
> the sensitivity list. If D changes and CP is 1, then
> CP'last_value is 0 and Q gets updated. Most RTL simulations
> will not notice the difference between a latch and a
> register, however, in most cases latches are bad for
> static timing analysis.

Lo and behold !
I will run some more simulations, but I think you are right.
It should be a latch... and .... we currently synthesize a latch for it too !
Thanks !!

>
> What if you remove D from the senstivity list above?
> The following by simulation semantics is a register.
> process (Clk)
> begin
> if (Clk = '1') then
> Q <= D ;
> end if ;
> end process ;

The only hardware that will be correct (without sens-list warnings) is a flip-flop.

>
> 1076.6-1999 was silent on what to do with this.
>
> In 1076.6-2004 it is an error and shall not produce hardware.
> This happens since, 1076.6-2004 requires all register coding
> styles to have edge semantics within the body of the process.
> 1076.6-2004 also requires all latch and combinational
> logic code to have a complete sensitivity list.
> Since the above example does not have edge semantics it
> cannot be a register and since it does not have a complete
> sensitivity list, it cannot be a latch or combinational logic,
> and, hence, it is an error.

Seems a bit harch to error out, considering that a correct
implementation is possible (with a flip-flop).

I thought we should not be a 'methodology cop' ?

Sorry, but I cannot change this to an error. Customers will kill me.

>
> Error and no logic is the right answer since some synthesis
> tools produce registers for this code and some produce latches.

I know what you mean.

>
> I suggest that you close your issue by explaining the above
> and citing 1076.6-2004.

Thanks for the tip.

>
>
[...]
>
>> Mmm. I think this (multi-edge register) issue is still different than other design checks.
>> The FUNCTION of the design cannot be guaranteed to stay the same
>> (through synthesis) if we do not have hardware elements that are sensitive to multiple edges.
>> That is why synthesis tools error out.
>
> If the hardware does not exist, error out.

So the HDL would be target-technology dependent ?
Runs if you map to one technology, but not is run to another ?

Oh, one other thing : which ASIC or FPGA technology HAS general purpose
dual-edge sensitive registers in their library ? I mean separate cells, not
special-purpose registers that are embedded inside some memory or so ?

>
> This is consistent with the 1076.6-2004 interpretation
> of sensitivity lists. Have you considered the true
> hardware implication of signals missing from the sensitivity
> list?
>

Yes. I know all about that.
I used to error out (rather than warn) about missing signals on sens list.
But overwelming customer complaints pushed me to the warning.
I will not change it back to an error any more...

>
>> Now, Dave Higton came up with this creative way to model dual-edge registers with standard primitives.
>> Is that what 1076.6 wants us to synthesize ?
> > Alternatively, we could issue a warning and ignore one clock or the other.
> > But personally I find that dangerous for beginners (since they tend to ignore warnings),
> > and it does not help advanced designers either (since they still get a single-edge flip-flop).
>
> 1076.6 does not specify the implementation, but
> as I suggested above, I think you should error out
> and not produce hardware.
>
> Designers need to be aware of technology specific
> code and provide an alternate architecture when the
> current code does not have a correct implementation.

I really strongly disagree with you here.

If you include this as a RTL coding style, then how is a designer supposed to
know that it is technology dependent rule ?
It may work for one technology, but not for another.
I think this contracts everything about the purpose of defining RTL coding rules.

Otherwize, we have gained nothing over technology specific instantiations....

I'm sorry Jim, you did not convice me.

>
> Cheers,
> 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


.

Loading