Basically, the most important thing about good code is good documentation.
1.) document the module interfaces, including any assumptions/requirements.
2.) make simple block diagram, avoid making complex meshes.
are you really talking about coding style, or engineering process?
A bit of both. For pure style:are you really talking about coding style, or engineering process?
Well I don't know about madalin1990, but I am certainly lurking this topic in the hopes of more hints on the engineering process from people that actually do this in a professional capacity. ;-)
How do you document your module interfaces, besides comment in HDL? Do you maintain a spreadsheet? Visio? Something else?
What do you use for block diagrams? I find that I hardly ever get beyond the "scribbles on A4" stage because of the threshold of making a digital version. Any good tools for this? Visio would probably do the trick, EXCEPT that I don't have any useful templates. And no co-workers / company either to provide such.
On the subject of more documentation ... how do you document your medium sized FSM's? Lets say 10 - 20 states or so. Small enough that it still makes sense to put in FSM, but large enough that you'd like a bit more besides comments in your HDL. I've tried a couple of things, but I was wondering what's being used in The Real World [tm].
And potential tip for xilinx users ... the recent versions of PlanAhead actually produce reasonably useful schematics to be used in documentation. In the olden days you could not drag components around, so you'd end up with whatever autogenerated arrangement it came up with. And it usually came up with crap.But now you can rearrange things so that it actually looks fairly decent. Also see Jim Wu's blog on this. Oh, and the generated PDF looks better than the screenshots in that blog.
</hijack>
true - I use a different order system clock(s), reset on top, and then group ports based on which entity/component/device they are connecting to, example2.) ports ordered in logical groups going from outputs, inputs, to clk/rst. rst is the last port. This style is _not_ common though.
[syntax=vhdl]
entity SerialAudioInterface_TX is
port (
pi_SysClk : in std_logic;
pi_aRst : in std_logic;
pi_AudioMCLK : in std_logic;
--
-- CS5381 I/F
--
po_MClk : out std_logic;
pi_LR_Clk : in std_logic;
pi_SClk : in std_logic;
po_ResetADC : out std_logic;
pi_SerAudioData : in std_logic;
pi_OverFlow : in std_logic;
po_MasterDiv : out std_logic;
po_MO : out std_logic;
po_M1 : out std_logic;
po_MasterSlave : out std_logic;
po_I2S_LeftJust : out std_logic;
po_HighpassFilter : out std_logic;
--
-- System Interface
--
po_InterfaceFromADC : out t_InterfaceFromADC
);
end entity SerialAudioInterface_TX;
[/syntax]
most companies I work for (I'm a freelancer) tend to use coding guidelines; usually ports should be relatively easy to identify based on the first two or three characters (po_, pi_, pio_), the same for constants (c_), types (t_) and enums (e_)3.) never name an input "x_out", nor an output "x_in" unless there are no other logical choices. avoid naming ports based on the signal they will connect to in a specific instantiation. (eg, alu_in should not be an output)
Comment lines should tell why you use the part and not how it works
An excellent thread with most valuable info of VHDL programming loved each part of it
Guys one clarification I need is this
Why is it so what benefit I get it if I know how the operations are done does it not seem t simplify the problem I am facing
Do clarify me
Code Verilog - [expand] 1 2 // generate a toggle signal always @ (posedge clock) toggle <= ~toggle; // poor choice of signal name :-P
Code Verilog - [expand] 1 2 3 // generate an enable every other clock cycle for the accumulator // which operates at half the clock frequency. always @ (posedge clock) accum_enable <= ~accum_enable; // good descriptive signal name :-)
Why is it so what benefit I get it if I know how the operations are done does it not seem t simplify the problem I am facing
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?