VHDL Coding Style Guide

[info_]

Thanks Mike,

Precision synthesis seems to do a very good job.

XST just goofs on the disabled tristate (but says so).
(and it seems it's another XST bug)

Synplify was reported to do fine too.

I still stick to my rule
But I sure will elaborate about this in the next release of the rule set !

Thx everybody for participating.

Bert Cuzeau

 

[Mike Treseler]

Sorry, but thats not correct in general for up to date
synthesize tools. You could be right if you refer the early days
of VHDL synthesis, mainly used for ASIC designs.

I use Leo and Quartus for synthesis,
and the latest versions can not do this trick yet.
I think having this option would be a good
thing for FPGAs since they do their own reset during download.

On the other hand, the resources for distributing
a user reset are also available on FPGAs
and I might hesitate to give up the option
of reseting the device without doing
a complete download.


-- Mike Treseler

 

[dutchgoldtony]

Hi Bert,

I found your coding rules really helpful and concise and will be making
a few cahnges in the future to the way I do things in the future.
Just one question, do you know of any resources / tutorials on using
scripts, tcl or otherwise for synthesis and simulation.
I've only recently started using macro .do files but only for
controlling the test outputs.

Cheers,
Tony

 

[Bert Cuzeau]

Hi Tony,

Thanks for the good words about the Coding Rules. It takes time to shape
up, publish, fix and keep up-to-date this kind of documents, but I think
it's worth it. (I should have done so earlier)
---

We use now Tcl a LOT.
Having to teach the language did help ;-) but the ground isn't very
difficult, just surprising at first. In the Doulos course, we teach a
lot in three days, including the basics of Tk, event programming etc...
There are lots of good books and free ressources available.

With ModelSim, you can tie VHDL events to Tcl events, which opens
virtually unlimited possibilities. (I think I put on my Website a small
example to read the date/time info from VHDL).

However, I'm NOT at all a fan of Tcl for writing testbenches !
(controlling the stimuli and checking the outputs)

Stimuli and output checking should be done in HDL !

Scripts are wonderful for task automation, like for synthesis and P&R.
With Quartus, it's a breeze.
With Modelsim, you can do also fancy things with Tcl to manage your
project, interact with the user, like for selecting a test scenario or
calling other utilities to prepare or exploit simulation files, or even
interact with actual peripherals...

Considering that Tcl is easy to learn and free, and seeing the
productivity improvement it does procure, I think it's a good investment.

Thanks,

Bert

 

[info_]

Precision Synthesis doesn't like signals initialized at declaration either.
(except for the tri-state that XST did mis !!!)

I've few doubts that DC or FPGA compiler would accept this, but
it would be nice if a chap could quickly check this.

So I'll definitely keep this rule & enforce it.
Advanced users will bend it at their own risks

Bert

 

[Kai Harrekilde-Petersen]

Precision Synthesis doesn't like signals initialized at declaration either.
(except for the tri-state that XST did mis !!!)

I've few doubts that DC or FPGA compiler would accept this, but
it would be nice if a chap could quickly check this.

DC will warn about decl time inits, and then ignore them.

Our internal guidelines is to use decl time inits for testbenches only.


Kai

 

[Neo]

Bert,
I was wondering what are the differences when having all the instances
described in a case statement versus only describing legal ones and in
others declaring "null". I didnt see any points on this in your coding
style document. for example-
process(...)
case(a) is --2bit value
when "00" => x <= val1;
when "01" => x <= val2;
when "10" => x <= val3;
when others => x <= val4;
end case;
end process;
Vs
process(...)
case(a) is --2bit value
when "00" => x <= val1;
when "01" => x <= val2;
when "10" => x <= val3;
when "11" => x <= val4;
when others => null;
end case;
end process;
How does this affect synthesis?

 

[Mohammed A khader]

Hi Neo,

There is no effect on synthesis. Synthesis tool works on 0's and 1's
only ( Exceptions are (1) X's for dont care which are again
considered either 0's or 1's for optimizing logic (2) Z's are
considered as tri-state ). That is optimiztion algorithms expects
signals to be either 0's or 1's.

There is surely difference in simulation. if 'a' is a std_logic
signal then it can take any of 9 values , hence any combination other
then '0' and '1' would assign val4 to x for the fist case . For
second case it is null means nothing.

-- Mohammed.

 

[Neo]

My actual question should have been, when the valid case combinations
is less than possible ones. anyway, I got it.
thanks.

 

[Bert Cuzeau]

Bert,
I was wondering what are the differences when having all the instances
described in a case statement versus only describing legal ones and in
others declaring "null". I didnt see any points on this in your coding
style document. for example-
process(...)
case(a) is --2bit value
when "00" => x <= val1;
when "01" => x <= val2;
when "10" => x <= val3;
when others => x <= val4;
end case;
end process;
Vs
process(...)
case(a) is --2bit value
when "00" => x <= val1;
when "01" => x <= val2;
when "10" => x <= val3;
when "11" => x <= val4;
when others => null;
end case;
end process;
How does this affect synthesis?

Hi Neo,

The probably even better idea is to code
when others => x <= (others=>'-'); -- if it's an array.

This way, if you remove a case in the list :
- the result is optimized at synthesis
- there is no feedback created
- the simulation will make it visible whenever you
are (incorrectly) trying to use the removed case

Bert

 

[lokesh_boddu]

Hi Bert

Thanks for you rules,i am getting them in use,they are very much useful.

could you please explain me how to write test benches in a very efficient considering at least few worst cases(would be better if u give me any document regarding)

BODDU