Everybody who uses VHDL has a different style. Some constructs are obvious, others are "why the h*** didn't I think of that earlier.
Some examples....
Bitwise AND of the elements in an 8 bit bus: A <= B(0) and B(1) and....... I'm already tired of this.
A <= (B = X"FF")
the result is boolean here but the expression is a lot quicker to write. Make it a 32 bit bus and that's hugely quicker. I only found this contrstuct recently when I had to do a 64 bit and and thought there must be a better way. Google helped
In VHDL2008 there are bitwise AND etc functions but I'm not sure if VHDL2008 is fully imlemented in the Xilinx tools. Same ideas for bitwise OR, NOR and NAND. I don't have a nice answer for bitwise XOR as needed in parity checks.
Multiplexer for the elements of an 8 bit bus (or any width)
MUX <= BUS(SELECTOR); where selector is an integer. Saves a big CASE or WITH statement.
MUX <= BUS(conv_integer(SELECTOR)); if SELECTOR is SLV
if SELECTOR < 11 then MUX <= BUS(SELECTOR); else MUX <= '0'; end if; --- 10 bit bus, making sure that if the selection is more than 10 the result is guaranteed zero.
(10-02-2018, 05:46 PM)`FRANK.C Wrote: [ -> ] (10-02-2018, 08:01 AM)ppppenguin Wrote: [ -> ]Frank, boolean type is almost essential in VHDL. Whenever you say something like B <= (S = X"25"); then B is boolean.
Hi Jeffery
For something like that I would currently write
if S = x"25" then B <= '1' else B <= '0';
I do this without even thinking, its the microcontroller programing creeping in.
Writing it proper using Boolean is much clearer and easier to read back.
As a beginner knowing where it is best to use Integer's, Boolean etc. was the difficult part but even with the limited experience that I have now it has become clearer. It's only as I learn and try to write VHDL that realize how elegant your files are.
The first microcontroller program I wrote functioned well but when I came back and looked at it a year later I cringed and immediately rewrote it as it was so badly written. I fear in a the future I will do the same with the VHDL files I have now.
Hi Trevor.
I started this project back in November 2016 and it has taken up all my spare time until now. I expect if I toted up all I have spent on it I could easily buy at least one if not two Aurora's but I am doing it for the challenge and also to learn although the more I learn the more I realize how little I know.
As for how much the parts for one would cost. I am putting together a parts list and I will post it here when complete but I would guesstimate between 80 and 100 euro. It looks small but there is still quite a number of components in it.
I would have liked to have got rid of the Development board and have everything on the one PCB but I couldn't justify doing that. The components on the Development Board would cost about 3 times the cost of the Development Board also I would need either larger PCB or a 4 layer PCB.
Frank
Hi Frank.
I could possibly justify the cost but not the time. Funny when working i seemed to have time but not now. What with us both having health issues and grand children time is at a premium.
Great project Frank
(10-02-2018, 05:46 PM)`FRANK.C Wrote: [ -> ] (10-02-2018, 08:01 AM)ppppenguin Wrote: [ -> ]Frank, boolean type is almost essential in VHDL. Whenever you say something like B <= (S = X"25"); then B is boolean.
Hi Jeffery
For something like that I would currently write
if S = x"25" then B <= '1' else B <= '0';
I do this without even thinking, its the microcontroller programing creeping in.
Writing it proper using Boolean is much clearer and easier to read back.
The truth is, though it looks neater, it makes precious little difference to the final generated code (assume the compiler is a decent one) as the code fit should treat both those statements the same.
Coding style is as much an art as it is science. What is critical is getting the architecture right AT THE START - the implementation style can impact code size and efficiency, but a broken architecture is death for the project.
Where coding style IS important is when others are also working on/maintaining the code - a consistent style is absolutely vital if a third party needs to understand it, as is documentation and sensible in-line commenting.
I always comment code, especially when non-obvious decisions are made as if I return to something complex years later (e.g. to modify the code for a different platform), the design rationale may have been long forgotten...
One system you might want to look at is
JavaDoc/Doxygen where tags in the comments allow you to generate a software architecture web site automatically -
Doxygen is freely available and is very widely used in professional circles.
It supports VHDL out of the box - just running it even on non-marked-up code will generate a web site that details all your routines, their parameters, the calling tree etc. Very easy to use and incredibly useful - whenever I'm presented with someone's code, the first thing I do is run Doxygen over it, then browse the generated architecture diagrams. Have a play.
EDIT: There is a branch of Doxygen with built-in Verilog support at:
https://github.com/avelure/doxygen-verilog
I might well give Doxygen a try. While my own VHDL is well commented it's still useful to have a diagram of what I intended. As for getting the architecture right that's a real can of worms. You do your best at the start and find that it goes horrible as you proceed. Modules get out of hand. VHDL modules are best kept to 1000 lines or less for ease of use. Some of mine have crept nearer 1500 and rising so I need to take decsions about how to split them up. Module interfaces want to be as clean and narrow as possible which can play a large part in the structure of a design. At the opposite extreme you can end up with loads of tiny modules. Can be useful if they're re-usable in different parts of the design but otherwise a nuisance to keep in mind and a good reason to use Doxygen.
With VHDL and Verilog it's strictly speaking wrong to call the process "compiling" though most of us use term casually. The correct term is "synthesis" Ultimately it's generating hardware, not object code. Optimisation in synthesis seems to vary from fairly aggressive to ******** aggressive. Good style helps the synthesis tools to give efficient hardware. So for FPGA targets (which is what we're discussing here) that means (to give 2 examples) plenty of pipelining and avoidance of overomplex if/then/else structures. The difference between using boolean and SL for signals should make no difference at all. It almost goes without saying that you don't put gates in clock lines. Keep designs synchronous and use the CE inputs of flipflops which are easily inferred in synthesis. For a TV related design there will be stuff running once per line. So make a CE signal in the horizontal timing logic and use it as CE for the vertical logic. In this example it would be clearer if the CE was boolean (if CE then rathe than if CE='1' then) but I made the decision to keep is as SL. It's distributed down a hierachy of modules and you're not meant to use boolean types in the entity to interface to a module. It works but is deprecated. Stick to SL and SLV for module interfaces.
process (CK) begin
if rising_edge(CK) then
if CE='1' then
Loads of counters etc
end if; -- CE
end if; -- CK
end process;
Remember that type conversion (between SLV/ integer/signed etc or between boolean/bit/SL etc) is totally free. Uses no resources at all. It's purely a matter of how you describe a binary signal or group of signals. Likewise concatenation and bus splitting such as:
MYBUS <= DOG & CAT & COW & SHEEP; (the animals are all SL, MYBUS is 4 bit SLV)
HORSE <= MYBUS(2); Splitting a SL out from SLV. You can't directly split out bits from an integer. Need to convert to SLV, unsigned etc first but this is still free.
Doxygen has a wizard that does all the config for you - just run the wizard and answer the questions - normally only takes a short time to run, so playing with the various settings and re-running is easy - it remembers settings in "projects". I love it and have always insisted that all the development teams I ran used it too.
My use of the term "compiling" was mainly because I wanted to keep to terms folk might know - "synthesis" is not (IME) in most people's lexicon
If you install the optional DOT package, it'll do full, clickable, call graphs too - can be extremely useful when trying to make sense of something obscure.
I also tend to use Eclipse as my IDE and
Notepad++ (knows about loads of languages, including Verilog & VHDL) for listings...
Hi Trevor
Sometimes work presents opportunity's to do a bit with the project. Like working that problem out while driving from A to B or better still while the customer is "venting".
Hi Nick
I do comment the code, I find them essential as without comments I find coming back to a file even after a week I am asking "why on earth did I do that!"
Thanks for the link to Doxygen, I gave it a try and it looks useful (screen shot below). I will have a better play later.
Hi Jeffery
I got the architecture completely wrong on my first attempt, I had a multitude of small modules and they were all in the Top level entity which turned into a complete mess of a rats nest of wiring, I eventually has to start again.
Frank
It's interesting that despite it being lines of code we still call it wiring. I sometimes call it plumbing
That's all the interconnections between modules in a design. It can end up as a real rat's nest, just like actual copper wires.
I have uploaded the diagram of the converter. There is nothing special in it most of it is straight from app notes.
All the capacitors are ceramic types, no electrolytic's at all. I understand that the ESR of a electrolytic can be an advantage in taming things down but I have been using ceramics from the start through many builds without any problems.
Frank
I have finally got to the end of this project. Some pictures of the finished converter are posted below.
On the back of the converter is RF out, power, audio and video in.
On the front is from left to right
Pattern switch which selects test card or grey scale
Tone switch which selects 400Hz or 1kHz audio tone.
Aperture switch which selects soft, medium or sharp interpolater apertures.
Equalising pulses on off
Pedestal on off
Aspect ratio 4:3 / 5:4.
Chanel selection covering channels 1 to 13
Power LED
405 Video out.
The aperture switch came about as I liked the 6 line interpolater, it gives a nice sharp picture, but I wasn't sure if the artifacts that it produces would be intrusive. So I decided to make the aperture switchable with the original two line as medium the 6 line as sharp and I adjusted the coefficients of the 3 line to give a softer aperture.
It would have been nice to have a full size (1/4" shaft) switch for Chanel selection but I couldn't find one that would fit in the space I had and anyways any of the PCB mounting types were expensive.
I have used two sections of the DIP switch (A and B) as a means of turning off the video and audio modulators to aid setting up. The other two sections (C and D) were left just in case they were needed, for now they just provide a means to carry out some basic tests on the converter.
Depending on there setting they will flash the front panel LED
if the 50MHz FPGA board clock is present,
if 27MHz video decoder clock is present and
if the Field ID pulse is present this proves that a valid PAL signal coming from the video decoder.
Presets provide adjustment of audio gain and carrier level for the audio modulator.
The front and back panel legends were just printed on colored paper and then laminated, they fit into the groves in the case provided for the front and back panels. I decided to call it "Hedghog" with just one "e"
I have made a change to the circuit posted in the last post. C38 and C39 have been reduced to 1pF. and the 15K resistors from pin 4 of IC4 and IC5 have been dispensed with.
A big thanks to all on this forum for all the support I got throughout this project and especially to Jeffrey for all his help.
Frank
If, on some erudite quiz programme, the question was: "What is the connection between a pineapple, hedg(e)hog, aurora and domino?" I don't think many people would get the right answer