VHDL on the Decline for FPGA Design - Page 1
Forum section: electronics / general

author: kfnight
author_rank: Regular Contributor
timestamp: June 06, 2015, 03:49:30 am
content: http://blogs.mentor.com/verificationhorizons/blog/2015/06/03/part-6-the-2014-wilson-research-group-functional-verification-study/What's interesting is that vanilla Verilog is steadily rising.

author: ivan747
author_rank: Super Contributor
timestamp: June 06, 2015, 03:53:08 am
content: How different are they, really? I'm getting taught VHDL in a couple of trimesters. I hope I'm not gonna learn what could become the COBOL of HDLs.

author: c4757p
author_rank: Super Contributor
timestamp: June 06, 2015, 04:08:07 am
content: It doesn't matter what you learn, any passable coder can pick up new languages with relative ease. You're still doing the same things with it.

author: miguelvp
author_rank: Super Contributor
timestamp: June 06, 2015, 04:41:13 am
content: VHDL will give you a stronger foundation.Interesting paper:http://www.angelfire.com/in/rajesh52/verilogvhdl.htmlIn a nutshell, Verilog is easier to learn but VHDL allows more control. Maybe System Verilog reaches the gap but I have not used System Verilog yet.Myself I did find Verilog easier but I'm determined to use VHDL instead, but for the top level I rather use the schematic form.As for COBOL, they did make a killing on the Y2K era, and I bet there are still job offers for the few that know Cobol and Report Writer well and they probably get paid in gold bars.Edit: seems I'm mistaken, I guess I'm glad I'm a C++ programmer instead:C++:http://www.indeed.com/salary?q1=C%2B%2B+Developer&l1=Cobol:http://www.indeed.com/salary/Cobol-Developer.htmlAnd for those that champion C or Java, well it's not too bad:http://www.indeed.com/salary?q1=C+Developer&l1=http://www.indeed.com/salary?q1=Java+Developer&l1=

author: John_ITIC
author_rank: Frequent Contributor
timestamp: June 06, 2015, 04:42:02 am
content: I've been told by "people in the know" that, apparently, in the U.S., about 50% use Verilog and 50% use VHDL. This seems to be confirmed by the chart. Also, VHDL is mostly used by engineers working with FPGAs for government.For my own work, I only use Verilog. I see no need to move towards SystemVerilog in my projects. I find VHDL utterly confusing and I would not agree that it is easy to switch from one to another.

author: Junkers
author_rank: Contributor
timestamp: June 06, 2015, 10:40:10 am
content: I feel the same way about switching between languages. I prefer VHDL myself, its strong typing style makes code more readable IMO.

author: AndyC_772
author_rank: Super Contributor
timestamp: June 06, 2015, 11:04:45 am
content: Quote from: ivan747 on June 06, 2015, 03:53:08 amThere's a lot more to writing code for FPGAs than just the syntax and semantics of the language.FPGA design is all about understanding how the device "executes" your code, and how very, very different it is from the sequential, one step at a time execution model that microprocessors and microcontrollers use.For example, the classic example of how NOT to swap two variables:a = b;b = a;...does actually work, and does produce the desired result, if you write it in VHDL (or Verilog, or whatever) and put it into a clocked process running on an FPGA.Once you get your head around the execution model, the fact that you may need to express intent using a different syntax won't be a problem.For what it's worth, I've been using VHDL on and off for the last 15 years or so. The language still works, and my next design will undoubtedly be done with VHDL too. Hopefully by the time it's deemed to be a dinosaur, I'll have long since moved on from actually writing code any more.

author: nctnico
author_rank: Super Contributor
timestamp: June 06, 2015, 11:35:13 am
content: Quote from: John_ITIC on June 06, 2015, 04:42:02 amI agree. I'm a VHDL user. To me Verilog looks like a netlist from a schematics CAD package and not something I would pick up easely. There is too little structure for me. Besides that VHDL can do much more powerful stuff because it is more a programming language than a hardware description language. Then again many people still describe hardware. Just for fun look for a priority encoder written in VHDL. The majority of the people will write a VHDL if-then-else line for each input combination and only a few will write a 3 line function which can do the job for any number of inputs. Also the VHDL syntax is rather lenghty. If you are just describing hardware you have to do a lot of typing.AFAIK SystemVerilog is trying to bridge the gap between VHDL and Verilog by combining the best features of VHDL and Verilog but it probably takes another decade to become really mainstream.

author: 6thimage
author_rank: Regular Contributor
timestamp: June 06, 2015, 11:55:07 am
content: Quote from: AndyC_772 on June 06, 2015, 11:04:45 amThat won't work in Verilog (as they are blocking assignments) - you need to doa <= b;b <= a;for the assignment to happen at the end of the clock cycle.I use Verilog - I come from a C background, and was given the opportunity to learn either Verilog or VHDL. I looked at VHDL and it just looks a hell of a lot more confusing - the code is split up a lot more into different blocks. Where as, Verilog allows the code to be cleaner and more compact.Additionally, there are several things that you can do in Verilog that have no VHDL equivalent - such as reductions (|r will or all the bits of r together, creating a 1 bit output) and repeated concatenations ({5{r}} is equivalent to {r, r, r, r, r}, this in VHDL would be r & r & r & r & r - which (from a C background) is frankly confusing).However, I believe that it is harder to create bugs in VHDL than it is in Verilog. As VHDL is more verbose (it can have 3 times as many lines of code as equivalent Verilog), it forces the programmer / designer to write in a certain way that removes the chances of making stupid errors. When you have been using Verilog for a while, you don't make these mistakes very often, and so you can write faster. (I remember reading about a little competition / test that was done to try and compare Verilog and VHDL, by getting people experienced in either one of them to create the same design in a very restricted amount of time - with only the Verilog programmers finishing, however, only half of them worked).In particular in Verilog, there is the difference between wires and registers, which can confuses newcomers (wires are assigned outside always blocks, registers are assigned in always blocks), there are blocking and non-blocking assignments (where the values are assigned immediately after an =, but at the end of a clock cycle for an <=) and setting a 5 bit register to a 1 bit value (or assigning a 1 bit wire to a 5 bit output of a module) is perfectly valid, and will only give a warning in most synthesisers (with simulators ignoring it entirely).On the whole, I think VHDL is likely to be declining because more people are used to C like languages. But I think it will always remain strong in certain areas, such as government, military and space (ESA chose VHDL to implement their LEON processor in).

author: codeboy2k
author_rank: Super Contributor
timestamp: June 06, 2015, 11:56:38 am
content: I have used both, and I much prefer VHDL over Verilog. This might be due to my own ancientness, growing up on strongly typed algorithmic software languages and languages that have modularity and packages much like VHDL at does heart.Todays kidshave grown up on javascript, ruby, python, et.al. and don't understand the need to have strong language types and deterministic behaviours.Verilog will happily convert between types for you and maybe do the wrong thing, VHDL won't. If I need a type conversion in VHDL I have to write a function (or use a package that has it already) but at least then I know that I am under control of the type conversion process, not at the whim of the compiler, which may get it wrong and I won't know until deep into the testing phase.I like the deterministic behaviour of VHDL, over Verilog's non-determinism. If you even just compile a Verilog project in the wrong order you can get different results. VHDL's Entity/Architecture pairs makes this a non-issue, and separate compilation in any order is possible. It's similar to C/C++ header .h and implementation .c files . Verilog's include statement is not the same.For now, I'm sticking with VHDL, but it is true that it is slowly getting left behind, and newer vendor tools are heavily focused on SystemVerilog (which I have not tried) and SystemC ( total yuck! gag me with a spoon )PS: here's an interesting point for those of us who say they have used Verilog, but not yet tried SystemVerilog.. apparently they are now the same, there is no more Verilog, and since 2009 there is only SystemVerilog. The 'old' Verilog is now a subset of SystemVerilog and included in the language.QuoteFrom that same paper, there is a Verilog to SystemVerilog growth chart, and SystemVerilog seems really rich, so I can understand its popularity among new designers. I might have to visit the dark side and give it a go once again

author: 6thimage
author_rank: Regular Contributor
timestamp: June 06, 2015, 11:59:09 am
content: Quote from: nctnico on June 06, 2015, 11:35:13 amSuch as?

author: 6thimage
author_rank: Regular Contributor
timestamp: June 06, 2015, 12:04:35 pm
content: Quote from: codeboy2k on June 06, 2015, 11:56:38 amI think that is the biggest drawback of Verilog - it is handy in some places, but it is so easy to do it by accident and it won't be picked up.Quote from: codeboy2k on June 06, 2015, 11:56:38 amWith the exceptions of defines, I don't think Verilog should have the include statement - all files in a project should be supplied separately to the synthesiser or simulator, then this is not an issue.But then again, it seems that VHDL forces a certain way, with Verilog you have to follow a set list of best practices to prevent silly errors.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 06, 2015, 12:57:50 pm
content: Noting that I haven't used lots of high level blocks and integration, and don't know Verilog,I was taught VHDL, and I fail to see what the big fuss is. Perhaps this is because my perspective is different.When I was told that VHDL is adescriptive language, not a sequential programming language, I understood this. It seems like almost no one ever comes to understand this, to see how (static, combinatorial) logic might be (literally) "spelled out".Moreover, synthesizers use a very small subset of VHDL; while a real digital logic circuit is perfectly capable of implementing a "delay(10ns)" or what have you, a synthesizer never will; it must be implemented by clock edges instead (which means dramatically more trouble, as you probably have to mux between phases of a PLL -- assuming you have such equipment available -- a PLL being, at heart, an analog function provided by proprietary interface and synthesis, not even realizable in VHDL on its own).When I write VHDL, I approach it entirely from the angle of RTL. What logic am I describing? It starts with a logic diagram, then the implementation follows, and the synthesizer output is checked for correctness (and device operation, and inevitable debug cycles..). When I talk VHDL with others, I find they regularly try to represent things as programmatical, which is fundamentally wrong; I always go directly to "what logic are you trying to synthesize?" -- and often get blank looks at an apparently alien approach!Since synthesizers are restricted to a subset, and I'm only trying to describe RTL, writing VHDL is very easy. Direct (combinatorial) logic operations can be implemented in an architecture. Sequential (latch/register) operations can be implemented in a process. Both can be used together, or much of it can be grouped inside the process (it always bothered me that the available combinatorial "conditional"/mux statements/blocks differ for the two areas). Or you can implement the freaking latches/flip-flops in 'bare metal' so to speak, but don't be surprised if the synthesizer (despite its vast compilational power) doesn't understand that you meant a regular latch, and you end up getting exactly the chain of gates you wrote, with subsequent poor performance. (But such is sometimes necessary, e.g. if you need to implement a dual clocked flip-flop. It's very easy to describe such a component in legitimate VHDL, but again, no synthesizer will make it for you.)Tim

author: nctnico
author_rank: Super Contributor
timestamp: June 06, 2015, 01:17:45 pm
content: Quote from: T3sl4co1l on June 06, 2015, 12:57:50 pmThat is -I'm sorry to say this- because they are right. Going at it from an RTL perspective entirely defeats the purpose of using an HDL. If you describe the function instead of the logic you'll get the job done in much less time and produce code which is much easier to understand, maintain and extend. I often need 3 lines of VHDL where others need 20.Your method is like using Karnaugh diagrams to reduce logic equations by hand while the software tool which can do that for you in less than 1 second is right in front of you.

author: Bassman59
author_rank: Super Contributor
timestamp: June 07, 2015, 11:05:09 pm
content: Funny, I have been seeing articles about VHDL's decline for 20 years now.I've used both Verilog and VHDL over the course of my career, and the decision as to which to use has always been made by employer. Thatsaid, I greatly prefer VHDL, and that's what we use on the job now.

author: Bassman59
author_rank: Super Contributor
timestamp: June 07, 2015, 11:10:38 pm
content: Quote from: nctnico on June 06, 2015, 01:17:45 pmI have to agree with this. If you're not taking advantage of the ability of the language to infer logic from behavioral descriptions, you might as well be doing schematic based designs. If you're not taking advantage of the language's strong typing, and as such using unsigned or signed or integers instead of std_logic_vector for math operations, you're making your life more difficult than necessary.VHDL is very powerful, and modern synthesis tools really do take advantage of its features. You don't need to write RTL code to get excellent results.

author: John_ITIC
author_rank: Frequent Contributor
timestamp: June 07, 2015, 11:18:28 pm
content: Quote from: T3sl4co1l on June 06, 2015, 12:57:50 pmI agree 100%. For my designs, I need to have maximum efficiency in the hardware implementation. There is no room for errors or for implementing inefficient designs. Therefore, I always carefully define my state machines in Excel (current state, outputs, transition criteria, next state), implement exactly as defined and simulate via test benches designed with the very same methodology.It is sometimes somewhat tedious to work highly structured this way but I have found that the quality of the work is consistently high and there are much less confusing bugs in the end implementation. Also, there is always a full correlation between the blue-print of the design and the actual implementation.I think that the level of abstraction one works on correlates with the details of the results one requires.Edit: In my designs (Protocol Analyzers) most of the FPGA logic deals with transferring chunks of data between registers and doing bit and byte manipulations such as byte reordering and descrambling. This is essentially all about manipulating data between registers so RTL is the correct abstraction level for my designs. Other designs deal with higher-level things and don't care about the lower-level implementations so higher-level abstractions and languages such as SystemVerilog might make sense. These hardware description languages are all tools and one should use the tool and abstraction level suitable for the job.

author: Marco
author_rank: Super Contributor
timestamp: June 08, 2015, 01:30:10 am
content: So basically you have a schematic entry tool in your brain which translates to VHDL using the architecture specific model of VHDL->FPGA translation which you also internalized.I'm sure it's the most efficient way, I see Xilinx doesn't even allow schematic entry any more in Vivado, but somehow it seems an inefficient use of neurons.

author: hamster_nz
author_rank: Super Contributor
timestamp: June 08, 2015, 02:33:59 am
content: From the Article:QuoteAlternative reading of numbers..... the number of design starts is increasing, and newcomers to FPGA game are choosing to use Verilog or SystemVerilog (for better of for worse).Also, how come do the percentages add up to more than 100% The imaginary purple (a.k.a. "projected design language adoption trends within the next twelve months") figures add up to about 180% by my eyeball).How can about 30% of designs be moving to SystemVerilog in one year, where the previous year's growth was 5%? That is like almost 1/3rd of all designs???Numbers look either wrong, dodgy, out of context, or made for marketing purposes to me...

author: John_ITIC
author_rank: Frequent Contributor
timestamp: June 08, 2015, 04:50:59 am
content: Quote from: Marco on June 08, 2015, 01:30:10 amFor my designs, I design via a traditional data-path / controller design-flow. I know where my data is coming from and needs to go and I carefully design state machines that precisely, on a cycle-by-cycle basis define what happens in the circuit at all times. The "controller" sets up the data paths (via muxes) for each cycle so it is precisely know what the end functionality will be.This is hardly "schematic entry" but I do know what the data path will look like before I enter the HDL. I must know or else I cannot guarantee that my implementation is optimal. I need to clock gigabytes worth off data through my FPGAs and need to squeeze out as much of the hardware as possible.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 08, 2015, 04:58:13 am
content: Hmmm...Am I perhaps correct in intuiting that "writing VHDL to implement RTL" is akin to assembly code, while "connecting high level blocks via VHDL" is akin to OOP? -- With precisely the same optimization, development and philosophical argument issues in place?Tim

author: John_ITIC
author_rank: Frequent Contributor
timestamp: June 08, 2015, 05:12:46 am
content: Quote from: T3sl4co1l on June 08, 2015, 04:58:13 amYes, that's precisely it. And if you look at any new PC applications that are being implemented, the art of writing tight code is lost. Any application these days take up 10's of Megabytes for no reason other than that the macro tools generate loads of fluff that the implementer may not even be aware of. Of course, the savings is in implementation time. But for those cases where cycle-by-cycle precise control is needed (for any reason) assembly language is still alive.I have worked as professional software developer for some 15 years and I see more and more that the newcomers have little to no understanding what goes on under the covers. The risk is the same with HDLs. An example is to design in SOCs on an FPGA just because it is available regardless whether it is suitable or needed. But I digress...

author: kfnight
author_rank: Regular Contributor
timestamp: June 08, 2015, 05:39:21 am
content: Quote from: hamster_nz on June 08, 2015, 02:33:59 amHi Hamster. That is discussed in the original blog post. Many FPGA designs are mixed-language designs.

author: Alexei.Polkhanov
author_rank: Frequent Contributor
timestamp: June 08, 2015, 07:24:37 am
content: Altera people like Verilog, Xilinx people like VHDL. Just my impression, maybe wrong, but if you look at sample code in Quartus and ISE it seems to confirm that. I am not aware of design tool that supports _all_ SystemVerilog.

author: slateraptor
author_rank: Frequent Contributor
timestamp: June 08, 2015, 09:19:17 am
content: Quote from: Bassman59 on June 07, 2015, 11:10:38 pmAlthough I somewhat agree with your points, proper inference is really an advanced topic that requires intimate knowledge of both the synthesis tool and low-level constructs.A software developer versed in high-level languages would likely not give a second glance at something seemingly harmless asc <= a + b;...yet knowing precisely what's synthesized (and why it doesn't work; alternative solutions) may very well mean the difference between 20 lines of code that satisfies cycle-accurate timing constraints or 3 lines of code that falls flat on its face. If you've ever had to interface with DRAM at a low level or other comparable high-speed application, these types of problems should be very familiar.What strikes me as baffling is our unwavering infatuation with code brevity, even when it means sacrificing precise control and determinism. If that additional 17 lines of code means I'll be instantiating precisely what I want, that sounds like a small price to pay if I don't have to think twice about it and I save a single day in debug/integration. I feel like this is the fundamental disconnect that traditional software developers without a formal hardware background have when dabbling with HDL...all they see is the "L" part while abstracting away the "HD" to a higher domain (or pretend that it doesn't exist altogether) even when it doesn't make sense to do so.Concerning math operations and numeric_std types, I'm sureHenry Warrenhas thought of more than few examples where std_logic_vector might make a little more sense in context.Concerning Kmaps and logic optimization, I was told a story of the time an older CCA's logic was being mapped to a CPLD. Long story short, synthesis tool kept optimizing away gates specified in the original design. Turns out the OG design engineer was smart enough to mitigate combinatorial glitches caused by gate propagation delays using additional (unoptimized) logic...the synthesis tool (at the time?) wasn't. It wasn't until a manual Kmap analysis was performed that the OG design intent was made clear.John_ITIC brings up a solid point about datapaths in FSM+D architectures. For any non-trivial pipeline that pushes the limits of a device's fabric, I'd approach the problem in a comparable way. But perhaps more importantly...Quote from: John_ITIC on June 07, 2015, 11:18:28 pm

author: slateraptor
author_rank: Frequent Contributor
timestamp: June 08, 2015, 09:33:01 am
content: Quote from: Alexei.Polkhanov on June 08, 2015, 07:24:37 amIf there's any correlation, it may have more to do with their dominant market than preference, that is to say commercial (Verilog) vs. defense/euro (VHDL).In the defense systems that I've seen and worked with to date, they've all been predominately Xilinx devices (+1 already obsolete Lattice CPLD)...even my current project, which integrates a XQV100 high-reliability Virtex.

author: tggzzz
author_rank: Super Contributor
timestamp: June 08, 2015, 09:34:48 am
content: Quote from: slateraptor on June 08, 2015, 09:19:17 amYes indeed.If you want to talk in HLL software terms, you will find there is a big split between those that like verbose languages in which the compliers catch problems, versus those that like to write few characters and not find (if they are lucky) problems until runtime - maybe when customers are running the application. I prefer the former, and believe the latter indicates they've only worked on new and small applications.QuoteAh yes, bridging terms. I repeatedly asked sales and pre-sales droids that question, andnevergot a satisfactory answer.

author: Wilksey
author_rank: Super Contributor
timestamp: June 08, 2015, 10:49:05 am
content: I have used Altera, Xilinx and Lattice parts, I have used Verilog briefly, VHDL and schematic capture other times, and I much prefer VHDL, all self taught through online literature, there does seem to be more available information in Verilog, and it seems as though the cheap Chinese dev boards from Ebay come with a ton of Verilog examples, but not many VHDL examples, personal preference is VHDL though.

author: hamster_nz
author_rank: Super Contributor
timestamp: June 08, 2015, 11:47:46 am
content: Quote from: nctnico on June 06, 2015, 01:17:45 pmOne thing that is starting to make itself obvious to me is that for the highest performance design, the HDL code looks like it has absolutely nothing to do with what is in the functional specification - usually the final form gets abstracted completely away from function. Once you get above about 150MHz or so you have to pipeline the snot out of everything and be very aware of the physical resources on the FPGA....For example, I've recently written code for HDMI output that generates two 10-bit TMDS codes per cycle, for feed into a 20:1 serializer. The end result is a short pipeline - Stage one looks up the encoded parity values for the two data values in a 256x12-bit table, stage two does the bulk of the work and uses the parity information to select which codes is being sent, totals up the running parity, and starts lookup of the 10-bit codes in a 1024x10-bit table. Then the final stage sends the two 10-bit codes off to the serializer as a 20-bit word. It looks nothing like the HDMI spec would have you believe it should... all the smarts are actually in a separate bit of C code that generates the contents for the tables. And it could be just as easily written in VHDL or Verilog, the actual code that does stuff is about 60 lines with 200 lines of lookup tables.Likewise with generating BCH codes, or calculating CRCs at multiple words per cycle, or implementing scramblers/unscramblers - and you can't get away from it. With FPGA clocking at a few 100MHz but data rates getting up to multiple Gb per second for the likes of Display Port, HDMI 2.0, 10G Ethernet or UHD video. You have to go very wide in your data processing, and keep down the per-cycle complexity of the logic as low as possible - and in a lot of cases you can't do that easily with code that is purely functionally descriptive.When it comes to inferring DSP functions things are much the same. I have a function that needs to calculate the square of a 35-bit signed number. When inferring with "b <= a*a;" it uses four DSP blocks, but the actual function only needs three. After telling it to do exactly what I want I can do 25% more work on the same FPGA. The design also had quite a few free LUTs, so if I put one of the remaining three multipliers that make up the square function in LUTs rather than a DSP block, and can now get nearly twice the processing out of the same FPGA.If you aren't working FPGAs hard then functional descriptions work really well and are preferred, but to get the best you really have to define the structure of what you want, and ensure that that structure maps nicely onto the underlying physical resources.

author: nctnico
author_rank: Super Contributor
timestamp: June 08, 2015, 12:37:34 pm
content: Quote from: hamster_nz on June 08, 2015, 11:47:46 amTrue but in many FPGA designs only a few percent of the logic works at high frequencies and is time sensitive while the rest is just management stuff running at lower clock frequencies. Then again it helps a lot to think about what you are doing. Optimising an algorithm usually results in a much better implementation than trying to squeeze the last bit of speed out of a not so efficient algorithm.One of my ongoing projects involves an FPGA design I inherited. It is quite large and includes a softcore with lots of peripherals. The original authors created peripherals using 'if write and address=0 then reg0=data;' for each register. Ofcourse that is a lot of work. Instead of thinking on using VHDL more efficiently they decided to cook up some Lua scripts to generate the VHDL for peripherals automatically and turning the design into an even bigger mess. For new peripherals I just create a 'registers' array and use a single line like 'if write then registers(address)=data' to write data into the registers. Write strobes same story and with an enumeration to use as array indexes the code is perfectly clear. Unused bits are automatically optimised away so no worries there. Experience tells me exactly what certain constructs end up looking like in the FPGA fabric but that is something anyone can learn. For example Xilinx has documents which describe how certain constructs are translated into FPGA primitives; follow those and you don't have to get into infering primitives directly to get the most from the FPGA.

author: Bassman59
author_rank: Super Contributor
timestamp: June 08, 2015, 04:00:13 pm
content: Quote from: slateraptor on June 08, 2015, 09:19:17 amFor what it's worth, I am not a fan of code brevity for the sake of brevity. I am a fan of code correctness, and that often means using variables for intermediates in a process (of course I am aware of the assignment rules for variables vs signals in VHDL), and that also often means just writing more code. And comments, which inform the readerwhyI do something (thewhathad better be obvious).QuoteI am not familiar with that book.QuoteAncient tools had issues, and of course if you read through the Xilinx or Altera forums, you see hundreds of posts asking, "Why did the synthesis tool remove the buffer I put in to add delay?" There are all sorts of reasons one might wish to add gate delay, but I suppose that in a fully synchronous design, it's never necessary. That's a debate for another thread ....QuoteI think we all agree on that!

author: Bassman59
author_rank: Super Contributor
timestamp: June 08, 2015, 04:14:10 pm
content: Quote from: nctnico on June 08, 2015, 12:37:34 pmFor those unclear on this idiom, you need to create an enumeration (or a list of constants) in a package which defines all of the register addresses (either as integers or std_logic_vectors or whatever you prefer).usethat package everywhere you reference the registers array. And when the registers get sent down to an entity through the port interface, you'd do something like this:u_registers : entity work.registersport map (clk => clk,registers => registers,foo => foo);u_uart : entity work.uartport map (clk => clk,baudrate => registers(REG_UARTBAUDRATE),stopbits => registers(REG_UARTSTOPBITS),tx => uart_tx,rx => uart_rx,.... );and so forth. This is where the notion of using the language features to enhance readability and maintainability and such really works. The logic that results from this will be the same as it is for the usual case statement implementation of register writes.

author: Marco
author_rank: Super Contributor
timestamp: June 08, 2015, 10:12:16 pm
content: Quote from: John_ITIC on June 08, 2015, 04:50:59 amYou say it's not schematic entry ... yet the abstract concepts you use to think in for designing the circuits certainly sound like the representations present in schematic view.VHDL obfuscates them by being so highly context and architecture dependent and RTL obfuscates them by the forest hiding the trees.

author: hamster_nz
author_rank: Super Contributor
timestamp: June 08, 2015, 10:36:22 pm
content: Quote from: Marco on June 08, 2015, 10:12:16 pmAnything that can end up in an FPGA must be able to be drawn as a schematic, but it doesn't mean it is the best representation - in fact most vendor's tools will do this for you if you want.I guess you might consider software souce code "schematic entry" for flow charts which reveal "the truer, deeper meaning of the code" - however I don't agree. A history of failed graphical code builders would point to readable source files having "something more" than schematics.Also, schematics have a whole lot of metadata that doesn't end up in the design - the location of objects on the schematic, the routing of the connections, colours, signals that tap into buses... you spend a lot of time making schematics "look pretty" that has no impact on function. This is why auto-generated schematics look so crappy.I am pretty sure that there are structures that you can code that can't be represented as reasonable schematics - in VHDL modules that reconfigure themselves based on generics, or use internal generate clauses to add and remove components, or make use of internal functions, or otherwise hides complexities).

author: Marco
author_rank: Super Contributor
timestamp: June 08, 2015, 11:07:10 pm
content: I'm not saying it's the right tool for the job ... I'm saying it's the only language which has an abstraction level close to the way he thinks of the circuit, whereas the alternatives are obfuscation. This to me seems more a failing of the textual HDLs than anything else.

author: John_ITIC
author_rank: Frequent Contributor
timestamp: June 09, 2015, 12:31:10 am
content: To expand the SW/HDL analogies:If software developers would take some time to actually design their software carefully and formally, for instance via use of state machines, before implementation would start, the end result would be much more thought through and easier to maintain. Just because higher-level languages exist, the temptation is simply too great so the end result is just to "hack away". These days there is even an industry trend to do "Agile development", which essentially means that the up-front design work is done away with and replaced by happy hacking. A sad trend - actually OOD started to become mature.I still maintain that the problem needs to be modeled on the level it occurs. There is no point in choosing a higher-level language than needed to solve the problem. For instance, for years there have been attempts to use C++ and other "object oriented" languages for system programming for Windows NT. Still device drivers are programmed in straight C - for the very reason that there is no need for higher-level languages such as C++ or C# when one merely is peeking and poking registers on some hardware device.For the same reason, I'm not interested in the new "Object Oriented" features of SystemVerilog. There is simply no need to abstract the problem at a higher level in my designs. For others it may make sense...

author: helius
author_rank: Super Contributor
timestamp: June 09, 2015, 06:20:44 am
content: Quote from: John_ITIC on June 09, 2015, 12:31:10 amAll OSX drivers are written in C++, they would not work otherwise. They implement subclasses of the base classes provided by the OS.OO is a very natural way to write drivers and solves many otherwise thorny problems. The ability to instantiate a driver object in response to some event, like a bus probe response, obviates the need to specify device numbers and communication methods at compile time.

author: nctnico
author_rank: Super Contributor
timestamp: June 09, 2015, 11:31:57 am
content: Quote from: John_ITIC on June 09, 2015, 12:31:10 amIn reality it doesn't work that way. Large software projects are first designed using UML and other systems design methods to get the flow and datamodel for a piece of software right. Then each module is coded by smaller teams.QuoteDid you ever look at the Linux kernel? It is entirely written using OO techniques in plain C. It is an utter mess. I'm convinced if they rewrite the Linux kernel in C++ it will be easier to maintain, has less bugs and will be faster. But it will take some time for the maintainers to see the light. Maybe the next generation. Just like C++ on microcontrollers took a long time to get some footing.QuoteOO is not just about abstracting. OO is about re-using pieces of code and let the compiler/synthesizer deal with the tedious jobs. It helps a lot to keep the data together with the functionality in one object.

author: tggzzz
author_rank: Super Contributor
timestamp: June 09, 2015, 01:02:28 pm
content: Quote from: nctnico on June 09, 2015, 11:31:57 amDon't be too dogmatic. Many projectsdon'tuse UML and many projectsareagile/XP.QuoteGiven the state of C++, using C isn't a bad decision. Read and understand the C++FQAathttp://yosefk.com/c++fqa/, and weep.

author: nctnico
author_rank: Super Contributor
timestamp: June 09, 2015, 01:58:15 pm
content: Quote from: tggzzz on June 09, 2015, 01:02:28 pmMaybe small projects but larger projects need a solid structure to build upon otherwise the developers will code themselves into a corner quickly.QuoteYou can write the same list with complaints about any programming language. It's funny to see how much effort people put into finding reasons to keep using the tools they know even though they are worse than the new ones.

author: tggzzz
author_rank: Super Contributor
timestamp: June 09, 2015, 02:24:15 pm
content: Quote from: nctnico on June 09, 2015, 01:58:15 pmThereby demonstrating you don't understand the agile/xp religion. Agile/XP has advantages and diadvantages. Waterfall/etc has advantages and disadvantages. Match the advantages/disadvantages to the task at hand - anything less is equally religious.QuoteSo you accept that the points are valid. Good. Those points are real, practical, serious and damaging to typical projects. C++ isand has to beschizophrenic - it is trying to be all thing to all people, and failing.Sometimes a simple well-understood devil is better than a new evolving poorly understood devil.

author: Muxr
author_rank: Super Contributor
timestamp: June 09, 2015, 03:36:04 pm
content: I'd say most modern sw projects use some sort of Agile, at least in all the places I worked at, except for one which used XP. Kanban is also gaining a lot of ground over Scrum when it comes to implementing Agile.

author: nctnico
author_rank: Super Contributor
timestamp: June 09, 2015, 03:43:18 pm
content: Quote from: tggzzz on June 09, 2015, 02:24:15 pmDon't twist my words into what you want to read. I'm not a 'the glass is never full type' so I really don't care what doesn't work in C++ (people already got around that) and use the things that do work. And the things that do work have an advantage over using plain C.

author: miguelvp
author_rank: Super Contributor
timestamp: June 09, 2015, 03:44:24 pm
content: Can we get back on topic, or is this thread doomed like most do?

author: tggzzz
author_rank: Super Contributor
timestamp: June 09, 2015, 03:54:16 pm
content: Quote from: nctnico on June 09, 2015, 03:43:18 pmYou (or your customers or bosses) will care about them when they bite you (or them). You need to know where the traps are, so you don't fall in to them.

author: miguelvp
author_rank: Super Contributor
timestamp: June 09, 2015, 03:58:47 pm
content: Quote from: tggzzz on June 09, 2015, 03:54:16 pmBut we don't care in this thread unless this has something to do with VHDL, Verilog or SystemVerilog.We are all well aware on your view of C vs C++, no need to bring it up every chance you get.

author: tggzzz
author_rank: Super Contributor
timestamp: June 09, 2015, 04:07:51 pm
content: Quote from: miguelvp on June 09, 2015, 03:58:47 pmWhich is a fair point; it has drifted too far.

author: Alexei.Polkhanov
author_rank: Frequent Contributor
timestamp: June 09, 2015, 11:59:50 pm
content: There is a connection, obviously.Slow succession of Verilog over VHDL can be explained by popularity of C/C++ over Pascal/Oberon/Ada syntax. It is certainly case for me - since I am a C/C++ programmer with 20 year experience I would naturally gravitate towards Verilog. I used to be a fun boy of Pascal and Ada but who is using them any more? Ada and VHDL have similar history - same people maybe involved and certainly same organisations - some committee in US DOD.Why C/C++/Java/Verilog syntax prevails over Ada/Pascal/VHDL? Probably multiple factors, mostly not technical I think...

author: Scrts
author_rank: Frequent Contributor
timestamp: June 10, 2015, 09:45:55 am
content: I also have experience doing software in C, but that was the main reason I've chosen to go with VHDL. That difference of the syntax creates a barrier in the mind and won't allow to do mistakes by thinking C and doing Verilog. I am happy with VHDL, which doesn't allow mixed bus widths and truncations.

author: Bassman59
author_rank: Super Contributor
timestamp: June 10, 2015, 06:54:23 pm
content: Quote from: Alexei.Polkhanov on June 09, 2015, 11:59:50 pmI honestly don't understand this discussion. The choice of HDL is made by your employer. Most HDL users are, in fact, employed by some company which has a history and a design process. So while you may love Verilog, if you get hired by a company that does VHDL, you'll learn to love VHDL.If you are a consultant, you use whichever language your clients prefer. If they have no preference, then choose the language with which you are most comfortable.If you're a hobbyist, you choose whatever you like, based on whatever criteria you find interesting.I will say, though, that choosing a language because the "syntax looks kinda like a language I already know" is silly, because Verilog's C-like syntax has enough deviations from C that you'll choke on them. (I don't know enough Ada to know whether anything I do in VHDL is actually like what you'd do in Ada.)

author: Alexei.Polkhanov
author_rank: Frequent Contributor
timestamp: June 11, 2015, 06:17:45 am
content: Quote from: Bassman59 on June 10, 2015, 06:54:23 pmNot entirely silly. I have been programming in many programming languages for living and for fun. With all languages or groups of languages comes certain philosophy and culture. Ada is more about verbosity in syntax, it is more readable but a bit harder to write code in. If your assumption that small differences can be a problem then how so many programmers, including myself, can switch from C to Java to Objective C to C# in one day many times and stay sane?So if you know C you will start producing good code in Verilog faster. Then there is articles and books that exploit similarity like here:http://www.embedded.com/design/real-world-applications/4006420/1/The-C-Programmers-Guide-to-VerilogI think Ada and VHDL are more academically sound languages that have some Niklaus Wirth's beauty in them. (He got Turing Award for designing Pascal).VHDL and Ada has lots of exact or similar syntax constructs. I think if Ada was more successful our world would be much nicer place to live in, but it did not happen.VHDL:CASE instruction ISWHEN load_accum =>accum <= data;WHEN store_accum =>data_out <= accum;WHEN load|store =>process_IO(addr);WHEN OTHERS =>process_error(instruction);END CASE;Ada:CASE X isWHEN 1 =>Walk_The_Dog;WHEN 5 =>Launch_Nuke;WHEN 8 | 10 =>Sell_All_Stock;WHEN OTHERS =>Self_Destruct;END CASE;Difference is only '<=' assignment.

author: tggzzz
author_rank: Super Contributor
timestamp: June 11, 2015, 08:33:14 am
content: Quote from: Bassman59 on June 10, 2015, 06:54:23 pmI agree.Syntax is trivial - even pretty dumb editors can help you get that right!Semantics are far more important, interesting, powerful - and problematic if you "don't think in the language". Old aphorism: you can write Fortran in any language.

author: nctnico
author_rank: Super Contributor
timestamp: June 11, 2015, 10:03:10 am
content: Quote from: Alexei.Polkhanov on June 11, 2015, 06:17:45 amIn my experience mastering a language is more than being able to read & produce the syntax. Being able to use a language efficiently requires learning the associated libraries and understanding the underlying philosphy. Definitely not something you'll achieve in one day!This also applies for making a HDL choice based on the employer or customer. If you know VHDL you are not going to apply for Verilog jobs / projects and vice versa.

author: hamster_nz
author_rank: Super Contributor
timestamp: June 11, 2015, 10:36:34 am
content: Quote from: nctnico on June 11, 2015, 10:03:10 amI don't know if that holds all that true for HDLs - for example most text books come in VHDL and Verilog editions, and cover exactly the same concepts, just with different code examples - for example "Introduction to Digital Design" by Richard E. Haskell & Darrin M. Hanna, or "FPGA Prototyping by [VHDL or Verilog] Examples" by Pong P Chu.I don't see that in any programming books that are in "language X or language Y" editions.

author: asgard20032
author_rank: Regular Contributor
timestamp: June 11, 2015, 10:46:20 am
content: Algorithm in C (Sedgewick)Algorithm in Java (Sedgewick)Algorithm in C++ (Sedgewick)--------------------------------------Programming C# Step by Step some random year (Microsoft press)Programming F# Step by Step some random year (Microsoft press)Programming Visual basic# Step by Step some random year (Microsoft press)

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: June 11, 2015, 12:39:27 pm
content: Quote from: asgard20032 on June 11, 2015, 10:46:20 amalso stuff likeModern Compiler Implementation in C - Andrew AppelModern Compiler Implementation in Java - Andrew AppelModern Compiler Implementation in ML - Andrew Appel

author: nctnico
author_rank: Super Contributor
timestamp: June 11, 2015, 12:54:43 pm
content: Quote from: hamster_nz on June 11, 2015, 10:36:34 amI wouldn't trust a book which has examples in different languages side by side. It won't show you the most efficient way of doing things in either language. For example if you want to sort data in C you have to do a lot of work using pointers and implement a clever algorithm yourself. In C++ you just use a STL container for the data and call the sort method.

author: hamster_nz
author_rank: Super Contributor
timestamp: June 11, 2015, 06:22:43 pm
content: Quote from: nctnico on June 11, 2015, 12:54:43 pmI don't trust the books, but here are a couple more exhibits for you:Exhibit #1- A 100 MHz SDRAM controller I wrote in VHDL.http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller#Version_0.5_-_Enhanced_debuggingExhibit #2 - The same SDRAM controller ported to Verilog, for a local university project that needed Verilog memory controller with a GNU header on it.http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller#Verilog_version_0.1- It was first Verilog project and it took me a few hours to port over a couple of nights.Exhibit #3 - From the the qsort() man page (qsort is part of the standard C library):Code:#include <stdlib.h>#include <stdio.h>static intintcompare(const void *p1, const void *p2){int i = *((int *)p1);int j = *((int *)p2);if (i > j)return (1);if (i < j)return (-1);return (0);}intmain(){int i;int a = { 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 };size_t nelems = sizeof (a) / sizeof (int);qsort((void *)a, nelems, sizeof (int), intcompare);for (i = 0; i < nelems; i++) {(void) printf("%d ", a);}(void) printf("\n");return (0);}

author: Alexei.Polkhanov
author_rank: Frequent Contributor
timestamp: June 12, 2015, 08:00:00 am
content: Quote from: nctnico on June 11, 2015, 10:03:10 amI have not seen single job ad for many years that does not require 'expert' knowledge of BOTH. Perhaps it is North American thing.

author: Bassman59
author_rank: Super Contributor
timestamp: June 12, 2015, 06:09:31 pm
content: Quote from: Alexei.Polkhanov on June 12, 2015, 08:00:00 amThat must be a big-company HR thing, because the last couple of times I've looked for a new job, the small companies all specified one of the languages, not both. I don't see how a small company can manage using both languages (or worse, adding SystemVerilog to the mix, or even more worse, adding some kind of C-to-gates shit) for design.What happens in any event is that you get into the interview and you ask, "what language do you all use?" and you'll get one answer.

author: kfnight
author_rank: Regular Contributor
timestamp: September 22, 2016, 08:54:06 pm
content: Mentor has the results in from their latest survey / study, with around 1800 participants. VHDL is still on the decline, and even vanilla Verilog. But look at SystemC / C / C++; more people are, or would eventually like, trying out (semi) high-level synthesis.

author: legacy
author_rank: Super Contributor
timestamp: September 23, 2016, 10:09:11 am
content: anyway, my attempt to merge up C with vhdl for testbench purposes has got some new progressI am using gcc + gHDL because I am experimenting this solution in order to test a new algorithm which converges ( I hope) to the exponentiation of complex numbersI has been studied on Mathematica, then ported to C, then moved from floatingpoint domain to fixedpoint domain (1), tuned (you have some significance loss issue), precision fixed, and finally moved from C to vhdlbut the testbench is still written in C, and I am interfacing it with the gHDL engine in order to test every blocks in the algorithm (e.g. the range-reduction block, the sign estimator block, the ReIm-network, etc etc)this strategy is better than the attempt of porting those tests to vhdl: also with C-gHDL I can have "pipes" which interact with the linux underground, therefore I can also interface inputs and outputs with Octave/Matlab/Mathematica, which also means I have a better screenshots to show(1) C++ offers the possibility to "overload" operators (+,-,*,/,%,=,>,<,>=,<=,!,...), so you can have a more comfortable fixedpoint engine which looks builtin the language and as good as the floatingpoint which comes really builtin and offered by the C language

author: aandrew
author_rank: Frequent Contributor
timestamp: September 23, 2016, 11:50:21 pm
content: Quote from: 6thimage on June 06, 2015, 11:55:07 amInteresting. I too come from a C background and I chose VHDL over Verilog specifically because it was NOT like C. I would get caught up writing C-like structures and of course that doesn't work overly well.There's also something I really quite like about strong (to put it mildly) typing in VHDL which really forces me to think about what I'm doing. I would never, ever want that in my C code though (integer promotion FTW).I also rather like the simplicity of VHDL; Verilog almost goads you into writing bad HDL because it allows you "think" in code. With VHDL I find I tend to "think" in HDL and writing good HDL in VHDL comes more naturally to me. I really do agree with Jan Decaluwe's assertion thatVHDL's crown jewel is the delta cycle; it's such a simple concept. The fact that this doesn't intrinsically exist in Verilog boggles my mind. I know that everyone writes their Verilog with the same idea in mind, but it feels like I'm fighting the language.In the end, excellent code is written in all of these languages, and people are continually trying to come up with new HDLs to make it even better.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: September 28, 2016, 10:46:38 pm
content: When I started working with FPGAs recently I learned both VHDL and SystemVerilog. My reasoning was that I should know enough about both to make a good decision as to which one to use long term, and also to be able to read examples in whatever language Ididn'tuse. I alternated languages for each new project and ultimately implemented all projects in both languages.After several months of using this dual language approach, I settled on SystemVerilog and use it almost exclusively now. I find the verbose syntax of VHDL too tedious and dislike having to cast everything to make it fit the data type I'm trying to use. Although I'm a long-time embedded C programmer (35 years), I've had no problems thinking in HDL and don't tend to write HDL code like I'd write C. I always keep in mind that I'm describing hardware rather than programming a CPU, so I don't find Verilog to be a disadvantage in this regard.SystemVerilog has some nice improvements over vanilla Verilog, so I recommend that beginners use it rather than Verilog if their development tools support it. I use Vivado and it has good support for SystemVerilog.

author: nctnico
author_rank: Super Contributor
timestamp: September 29, 2016, 12:45:49 am
content: If VHDL is longwinded and you need to cast everything then you are not planning your projects right and are thinking too in hardware instead of describing a problem.

author: Someone
author_rank: Super Contributor
timestamp: September 29, 2016, 01:58:22 am
content: Quote from: nctnico on September 29, 2016, 12:45:49 amDoing arithmetic operations and sending results to-from ram is a common example of needless casting since you can only address with an integer type, or the different ternary functions for different contexts when in verilog they are uniform. You either like strongly typed languages or you don't, neither is superior.

author: nctnico
author_rank: Super Contributor
timestamp: September 29, 2016, 08:22:22 am
content: If you define the ram as an array of the type you are using for the arithmatics you don't need to cast anything for source/result. A lot of this comes down to planning the types during the design stage. In my experience you should avoid std_logic_vector for anything which is a number (whether it is a value or an index). You'll see that you won't be using std_logic_vector at all except for signals which really need to be bit field.

author: AndyC_772
author_rank: Super Contributor
timestamp: September 29, 2016, 10:20:07 am
content: I think the point here is that the address and data inputs to a hard RAM block are STD_LOGIC_VECTORs, like it or not.Quartus will accept something along the lines of:Code:my_memory: dpram PORT MAP (address => CONV_STD_LOGIC_VECTOR (a, 8),data => CONV_STD_LOGIC_VECTOR (d, 8));... but ModelSim will choke on it, and insist on:Code:a_vec <= CONV_STD_LOGIC_VECTOR (a, 8);d_vec <= CONV_STD_LOGIC_VECTOR (d, 8);my_memory: dpram PORT MAP (address => a_vec,data => d_vec);Do you know of a more elegant solution?

author: nctnico
author_rank: Super Contributor
timestamp: September 29, 2016, 03:26:38 pm
content: Simple: create an array and let the synthesizer infer memory. That way you can always scale a design up and down without having to care what kind of memory resource is to be used. Ofcourse you have to keep the memory structures supported by the hardware in mind so you aren't creating something which the synthesizer can't deal with.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: September 29, 2016, 04:14:23 pm
content: Quote from: nctnico on September 29, 2016, 12:45:49 amI'm curious--when you're writing embedded code for an MCU do you use Ada?

author: nctnico
author_rank: Super Contributor
timestamp: September 29, 2016, 04:25:08 pm
content: Quote from: Sal Ammoniac on September 29, 2016, 04:14:23 pmNo but that is mostly due to lack of (embedded) ARM support for Ada.There are many things I'd like the 'language' to do for me in order to reduce the chances of programming errors. Think about bounds checking, not needing pointers all the time, etc. At some point using C gets tedious because you have to do so many things yourself if you want to create robust software.

author: chris_leyson
author_rank: Super Contributor
timestamp: September 29, 2016, 05:36:36 pm
content: QuoteProbably a lot of truth in that, ESA did a nice set of VHDL guidelines back in '94 which makes for a good read, not sure if they use Verilog though, but probably a lot of companies stick to one or the other if they have large development teams. I'm self taught in VHDL only because I couldn't get my head around the Verilog syntax, shame really it would be nice to be proficient in both not that I am that proficient at VHDL anymore havn't used it in 10 years.Nowadays both VHDL and Verilog are taught at university so maybe there is a bias in the education system somewhere that has filtered through into industry but then again it might be that VHDL is too verbose.

author: helius
author_rank: Super Contributor
timestamp: September 29, 2016, 08:56:14 pm
content: Quote from: nctnico on September 29, 2016, 04:25:08 pmC++ can do many of those things, with vectors and iterators. It does come with many of its own pitfalls, and library sizes tend to be huge.

author: nctnico
author_rank: Super Contributor
timestamp: September 29, 2016, 09:31:01 pm
content: Quote from: helius on September 29, 2016, 08:56:14 pmUsing a library for use on a SoC or PC isn't going to be the best idea but the principles can be used to generate similar functions with a smaller footprint. I really need to get into using C++ on ARM controllers!

author: Someone
author_rank: Super Contributor
timestamp: September 29, 2016, 10:42:22 pm
content: Quote from: nctnico on September 29, 2016, 08:22:22 amThe address of inferred rams is required to be an integer, so you cant happily sit in a single type domain and work away, and when you do want to compare data and addresses you're forced to do casting/type conversion.Similarly unsigned and signed types need to go through an intermediate type before being used with each other, its not a bad thing but its a very roundabout way of designing and adds unnecessary complications when you want to move data around. I can be sure that certain steps in a computation are guaranteed to be unsigned due to upstream constraints, but trying to tell the synthesiser that information in VHDL is very obtuse.