Author Topic: VHDL on the Decline for FPGA Design  (Read 27197 times)

0 Members and 1 Guest are viewing this topic.

Offline slateraptor

  • Frequent Contributor
  • **
  • Posts: 833
  • Country: us
Re: VHDL on the Decline for FPGA Design
« Reply #25 on: June 08, 2015, 09:33:01 am »
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.

If 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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: VHDL on the Decline for FPGA Design
« Reply #26 on: June 08, 2015, 09:34:48 am »
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.

Yes 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.

Quote
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.

Ah yes, bridging terms. I repeatedly asked sales and pre-sales droids that question, and never got a satisfactory answer.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Wilksey

  • Super Contributor
  • ***
  • Posts: 1329
Re: VHDL on the Decline for FPGA Design
« Reply #27 on: June 08, 2015, 10:49:05 am »
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.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: VHDL on the Decline for FPGA Design
« Reply #28 on: June 08, 2015, 11:47:46 am »
That 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.

One 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.


Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: VHDL on the Decline for FPGA Design
« Reply #29 on: June 08, 2015, 12:37:34 pm »
That 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.
One 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....

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.
True 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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: VHDL on the Decline for FPGA Design
« Reply #30 on: June 08, 2015, 04:00:13 pm »
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.

For 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 reader why I do something (the what had better be obvious).

Quote
Concerning math operations and numeric_std types, I'm sure Henry Warren has thought of more than few examples where std_logic_vector might make a little more sense in context.

I am not familiar with that book.

Quote
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.

Ancient 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 ....

Quote
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...

These hardware description languages are all tools and one should use the tool and abstraction level suitable for the job.

I think we all agree on that!
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: VHDL on the Decline for FPGA Design
« Reply #31 on: June 08, 2015, 04:14:10 pm »
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.

For 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). use that 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.registers
    port map (
        clk => clk,
        registers => registers,
        foo => foo);

u_uart : entity work.uart
    port 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.
 

Online Marco

  • Super Contributor
  • ***
  • Posts: 6693
  • Country: nl
Re: VHDL on the Decline for FPGA Design
« Reply #32 on: June 08, 2015, 10:12:16 pm »
For 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.

You 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.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: VHDL on the Decline for FPGA Design
« Reply #33 on: June 08, 2015, 10:36:22 pm »
You 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.

Anything 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).
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Online Marco

  • Super Contributor
  • ***
  • Posts: 6693
  • Country: nl
Re: VHDL on the Decline for FPGA Design
« Reply #34 on: June 08, 2015, 11:07:10 pm »
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.
 

Offline John_ITIC

  • Frequent Contributor
  • **
  • Posts: 507
  • Country: us
  • ITIC Protocol Analyzers
    • International Test Instruments Corporation
Re: VHDL on the Decline for FPGA Design
« Reply #35 on: June 09, 2015, 12:31:10 am »
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...
Pocket-Sized USB 2.0 LS/FS/HS Protocol Analyzer Model 1480A with OTG decoding.
Pocket-sized PCI Express 1.1 Protocol Analyzer Model 2500A. 2.5 Gbps with x1, x2 and x4 lane widths.
https://www.internationaltestinstruments.com
 

Offline helius

  • Super Contributor
  • ***
  • Posts: 3632
  • Country: us
Re: VHDL on the Decline for FPGA Design
« Reply #36 on: June 09, 2015, 06:20:44 am »
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.
All 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.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: VHDL on the Decline for FPGA Design
« Reply #37 on: June 09, 2015, 11:31:57 am »
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.
In 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.
Quote
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.
Did 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.
Quote
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...
OO 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.
« Last Edit: June 09, 2015, 11:45:05 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: VHDL on the Decline for FPGA Design
« Reply #38 on: June 09, 2015, 01:02:28 pm »
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.
In 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.

Don't be too dogmatic. Many projects don't use UML and many projects are agile/XP.

Quote
Quote
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.
Did 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.

Given the state of C++, using C isn't a bad decision. Read and understand the C++ FQA at http://yosefk.com/c++fqa/ , and weep.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: VHDL on the Decline for FPGA Design
« Reply #39 on: June 09, 2015, 01:58:15 pm »
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.
In 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.
Don't be too dogmatic. Many projects don't use UML and many projects are agile/XP.
Maybe small projects but larger projects need a solid structure to build upon otherwise the developers will code themselves into a corner quickly.
Quote
Given the state of C++, using C isn't a bad decision. Read and understand the C++ FQA at http://yosefk.com/c++fqa/ , and weep.
You 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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: VHDL on the Decline for FPGA Design
« Reply #40 on: June 09, 2015, 02:24:15 pm »
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.
In 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.
Don't be too dogmatic. Many projects don't use UML and many projects are agile/XP.
Maybe small projects but larger projects need a solid structure to build upon otherwise the developers will code themselves into a corner quickly.

Thereby 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.

Quote
Quote
Given the state of C++, using C isn't a bad decision. Read and understand the C++ FQA at http://yosefk.com/c++fqa/ , and weep.
You 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.

So you accept that the points are valid. Good. Those points are real, practical, serious and damaging to typical projects. C++ is and has to be schizophrenic - 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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Muxr

  • Super Contributor
  • ***
  • Posts: 1369
  • Country: us
Re: VHDL on the Decline for FPGA Design
« Reply #41 on: June 09, 2015, 03:36:04 pm »
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.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: VHDL on the Decline for FPGA Design
« Reply #42 on: June 09, 2015, 03:43:18 pm »
You 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.
So you accept that the points are valid. Good. Those points are real, practical, serious and damaging to typical projects. C++ is and has to be schizophrenic - it is trying to be all thing to all people, and failing.
Don'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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: VHDL on the Decline for FPGA Design
« Reply #43 on: June 09, 2015, 03:44:24 pm »
Can we get back on topic, or is this thread doomed like most do?
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: VHDL on the Decline for FPGA Design
« Reply #44 on: June 09, 2015, 03:54:16 pm »
You 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.
So you accept that the points are valid. Good. Those points are real, practical, serious and damaging to typical projects. C++ is and has to be schizophrenic - it is trying to be all thing to all people, and failing.
Don'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.

You (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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: VHDL on the Decline for FPGA Design
« Reply #45 on: June 09, 2015, 03:58:47 pm »
You 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.
So you accept that the points are valid. Good. Those points are real, practical, serious and damaging to typical projects. C++ is and has to be schizophrenic - it is trying to be all thing to all people, and failing.
Don'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.

You (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.

But 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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: VHDL on the Decline for FPGA Design
« Reply #46 on: June 09, 2015, 04:07:51 pm »
You 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.
So you accept that the points are valid. Good. Those points are real, practical, serious and damaging to typical projects. C++ is and has to be schizophrenic - it is trying to be all thing to all people, and failing.
Don'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.

You (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.

But 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.

Which is a fair point; it has drifted too far.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Alexei.Polkhanov

  • Frequent Contributor
  • **
  • Posts: 684
  • Country: ca
Re: VHDL on the Decline for FPGA Design
« Reply #47 on: June 09, 2015, 11:59:50 pm »
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...

 

Offline Scrts

  • Frequent Contributor
  • **
  • Posts: 797
  • Country: lt
Re: VHDL on the Decline for FPGA Design
« Reply #48 on: June 10, 2015, 09:45:55 am »
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.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: VHDL on the Decline for FPGA Design
« Reply #49 on: June 10, 2015, 06:54:23 pm »
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...

I 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.)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf