Re: [vhdl-200x] VHDL enhancements wish list

>..
>I will throw in a couple:
>For flip-flops, I would like to facilitate the re-use of
>intellectual property by having an abstraction that allows
>higher level changing of polarity of clock and reset, as
>well as, changing between asynchronous and synchronous
>reset.

The reset polarity is just a generic right? the clock polarity is also just
a function which you can change and I suspect that VHDL2008’s generics on
packages can make this quite elegant. You can of course also just invert the
clock (delta cycle issues taken into account) :-).

The async/sync reset is more difficult, however, this can be done (and is
being done) by a synthesis tool. XST for example (and I suspect others)
supports this as asynchronous reset costs extra in area and routing
resources in a Xilinx FPGAs. You can also just code both sync and async
resets and rely on the synthesis tool to remove the unused logic.

>Let me throw out a general question, how do we move
>to the next higher level of description where the
>amount of pipelining is not known at the start of
>the design and perhaps may be different for different
>usages of the same block. Are generics effective?
>Do we need a way for a synthesis tool to determine
>this and feed it back to us?
>Some of the C synthesis tools seem to be taking blocks
>without flip-flops specified and adding them at
>appropriate places. Is this the future?

In my opinion definitely, I have seen a few demo's of one of the ESL
synthesis tools and I was quite impressed. The fact that you can play with
the architecture (resources, pipelining etc) without changing a bit of your
(untimed) code is very impressive. Most of the ESL tools now also support
SystemC so you can mix untimed logic with traditional RTL style code. These
tools are not perfect as throwing a bunch of C++ code at any of these tools
will not give you good result but they are improving rapidly.

> Is there
>VHDL syntax that would simplify this process for the tools?

I think that we should forget about behavioural synthesis for VHDL as this
is clearly the domain of ESL languages. Also I suspect that getting ESL
vendors to adopt behavioural VHDL is probably a few magnitudes down from EDA
vendors supporting the next VHDL standard :-)

>Going back to the SystemVerilog. Always_ff,
>always_comb, always_lat assign logic intent to
>code and requires a simulator to check for basic
>hardware correctness. For me, a synthesis tool
>already does this (flags sensitivity list issues,
>reports warnings on latches and generally reports on
>the flipflops it creates). I don't need the simulator
>to do this too.

I fully agree, synthesis tools are pretty good at reporting latches,
memories, SRL, FF etc. A few lines of Tcl will give you a nice report at the
end of synthesis/P&R.

> In addition, if we assume "report
>all latches" (like a synthesis tool does), and adopt
>process(all) for combinational logic and use
>rising_edge/falling_edge for all flipflops,
>then the information is there - if only I am willing to
>pay for a vendor to implement the checks :).

That is a good idea, process(all) should not infer a FF/Latch or should give
a warning if rising/falling_edge functions are used. The way to get this
adopted is for all maintenance paying users to raise an ER (enhancement
request) with their vendor.

>I think we need to keep talking about the requirements
>for flip-flop coding and agree upon them before we go
>forward and start worrying about the implementation.

Without putting down anybody's idea, I think we should focus on the major
issues first and not on slight language changes. We should look at the whole
picture from RTL to the bitstream/requirements/model and see what is
missing. We should then focus on the most critical points, that is those
that cannot be handle by a downstream tool, pre-parser, linting tool, tcl
script etc.

I also believe we should discuss features (like the VHDL DPI) and create a
draft standard as soon as possible. The reason for this is that EDA vendors
are already adding features to their products and following a draft standard
is probably more cost effective for them than adding a second method when
the standard comes out.

Regards,
Hans.
www.ht-lab.com

>Best,
>Jim

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.