Author Topic: What HDL to start with  (Read 16579 times)

0 Members and 2 Guests are viewing this topic.

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15326
  • Country: fr
Re: What HDL to start with
« Reply #75 on: April 03, 2020, 01:54:55 pm »
You know what, you are absolutely right! No idea how I managed to mangle those info tidbits together.  :palm: Best guess ... probably managed to grab the "enumeration vs macro"related bit from Basssman59's post, then read your post containing "yes X and Y can .* macro .*". Then called `BRAINFART .

No problem. As nctnico added, if you use "macros" to define constants, sure there is some link with enumerations. But isn't there another mean of defining constants in Verilog than using macros? (Don't know enough of Verilog here...)

True enumerations (such as what VHDL offers, and I guess SystemVerilog offers something similar?) are a lot more than just constants. (Some may be influenced by C's enum - which is nothing more indeed than just a list of constants, but in C++ they are closer to true enumerations.) They represent a finite set. The benefit is not just for synthesis - it's already a benefit from a coding perspective.

 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27935
  • Country: nl
    • NCT Developments
Re: What HDL to start with
« Reply #76 on: April 03, 2020, 05:29:37 pm »
For delays i create macros that would load a value on a counter

`define after system_ticks[15:0] <=

always@(posedge clk) begin

// note that this tick counter here needs to be ABOVE the state machine so we can override the counter value
if (tick) begin
     system_ticks <=system_ticks -1;
     if (system_ticks ==0) system_ticks <=0;
  end
end
This would be great for a book titled 'coding styles straight from hell'  >:D I have a nice sub-title too: 666 ideas for when you want to be the only one to ever be able to work on a project.
« Last Edit: April 03, 2020, 05:42:02 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8550
  • Country: us
    • SiliconValleyGarage
Re: What HDL to start with
« Reply #77 on: April 03, 2020, 08:31:00 pm »

Macros, in this case, are obfuscators.

Nope. -sigh- This is always the case when trying to explain something on a forum... i try to give the minimum info so it would be clear what the intent is. But then it is misunderstood.
This has nothing to do with obfuscation, on the contrary. It is intended to make it easier to create state machines and logic that can sync up .

You make definitions for all kinds of events and items that need to happen at certain timestamps. in essence you are creating a language in which you describe the machine and what it does, what it waits for , how long , what it syncs with and so on.
these 'keywords' are then defined as verilog backticks ( `define ....)

When reading the machine description you don't need to wade through a bunch of complicated syntax. It is an english text that describes what happens. The underlying verilog can be complex and be a block of separate modules.
Code: [Select]
case revolution_state
    case `index
         `start_revtimer;
         `wait_for_sector_sync;
   case `first_sector;
         `get_sectorcount;
         `current_sector <=1;
         `start_sector_handler;
         `wait_for_sector_sync;
   case `last_sector
          blabla...
   default `wait_for_revolution_sync;
If this machines flow needs to change it is easy to understand where to alter the code.

In semiconductor design many systems are built like that. They use TCL or some other scripting tool to describe the desired system in a macro language. that then gets translated into instantiated block of verilog that are full of such `defines. the low-level designers make the primitive blocks needed and the `define headers. The rest is driven from outside the verilog world.

Nobody reads the actual 'generated' verilog code. A module is designed, simulated and done. How the modules fit together and interact with each other : that verilog is never seen by humans as it is generated by another tool.
I had over 300 control registers that needed mapping into dual port memory or hard registers. One side goes to the cpu , the other is hardware. I made a software tool where i can describe the registers and their layout and it would generate the verilog, the c code for the ARM , the C code for the 8051 , the transport code for the USB packet handler and the Visual basic code to throw visualize the data.

example

reg 0 r/w ,[15:14] state, [13] ready,[12:0] version;
reg 1 w, [15:13] 0, [12:0] desired_speed;
reg 1 r, [15:13] 0, [12:0] current_speed;

This would define the registers in the fpga and map them through an address decoder.
On the ARM you got a variable defined hard cast at adresses that map into the FPGA
In the arm code i could just write  desired_speed = current_speed +1; since both are hard mapped there is no 'i/o code'

In visual basic an object was created called current_speed. if you 'read the object' a call us done over usb to a c function on the 8051 that picks up the data from the dpram in the fpga and returns it.
same thing with desired_speed. all that stuff was totally handled 'under the hood'.

When a new chip came along all i had to do was write the layout of the registers . write-only registers were automatically 'shadowed' in the fpga so neither ARM nor 8051 nor pc had to do any of that.
The realtime code on the arm was a short program to spin up the motor and perform seek operations. That would have been impossible due to latency and command jitter in usb. So the ARM did those things in lock-step with assistance from the FPGA.
the 8051 code was just i/o transport into the registers and dpram. That was hardcoded and never needed altering as the 'mapping' was handled by the fpga.

Basically the top level program did not deal with registers. If a register contained mulitple bit fields , those all became individual 'variables' or 'objects' that could be read and written. The FPGA verilog made sure to 'assemble' all the required bits and pieces to form the true 'register' content and blast that of into real control register. The software did not have to do and/or masking to alter 1 bit in a register. The bit was accessible as a boolean.

Development of the platform went from months to half a day. Spend an hour making the table, send it through the compilers and while waiting for synthesis ,write the UI and ARM code. The verilog took 3 hours to synthesize. It filled the largest Cyclone-5 to 80% capacity . I think that was a 35 million gate device. on some large SOC with hundreds of registers and thousands of variable the verilog was hundreds of thousand of lines)

The tool create a .h file for the arm , a .h file for the 8051 a .vb file for the user interface and a .v file defining all the registers and the access code for them. In the FPGA the logic would 'trap' a write operation to a variable and fire of the serial protocol handler to shift out the entire register contents into the SOC. The protocol handler was also 'programmable' and the protocol had its own description language.

The user interface on the pc used custom control i designed that would lock onto the 'variable' objects. Building the UI was a matter of hours.

The whole system had the processors run in lockstep with the FPGA. The fpga generated the clock for the cpu's and it controlled the bus cycles. The fpga emulated the ram and rom for the ARM so the processor did not know that behind a memory location there was actually an enormous block of logic that disassembled and reassembled registers.

Why not do this in software ? because the hardware can do it much faster !
Think about it this way :
you have an SPI bus accessing a 16 bit register. this register has 3 fields. bits 15 to 11 , bits 10 to 6 and 4 to 0. called x, y and z

you need to write a piece of code on the cpu that does the following
x = ((y+3) *z)/32

So you need to call an spi handler to read the register , then you need to unpack the bitfields to create 3 integers , then you do the calculation , then you need to repack because you need to leave Y and Z intact but only need to update the bits 15 to 11 (x) and then you need to do another spi operation. 

My system : i didn't do diddly squat. X Y and Z are all variables hard located somewhere in 'ram' of the processor. The Fpga knows they are each 5 bit but it gives these to me as three  int32 with the highest bits already set to 0 so all the bit masking and shifting is handled in hardware. actually it is not even 'shifting' as all this stuff is done in 1 clocktick.

Code: [Select]
reg something [15:0]
`define x_read data_out[15:0] = {[15:5] 0 , something[15:11]}
`define y_read data_out[15:0] = {[15:5] 0 , something[10:5]}
`define z_read data_out[15:0] = {[15:5] 0 , something[4:0]}
`define x_write something[15:11] <=data_in[4:0];

always_reg @posedge clk
  if  (write_event) begin
     case address
        variable_x : x_write;
.....
case read_cycle :
   - perform SPI access to fetch register contents
 

always_comb read_system begin
  case read_address
    variable_x : x_read;
    variable_y : y_read;

The fpga runs the bus cycle of the processor. When it sees a read event come in it knows the target address. The cpu will only pick up the data 8 clockticks later. ( Hard defined by the ARM bus cycle. You could set the cycle independently for read and write. Write was single cycle , but read was 8 clock ticks. The arm bus clock is 50MHz (generated by the FPGA in sync with its masterclock) . The FPGAs internal clock is 500MHz.... that gave me 80 FPGA clockticks... i need 8 ticks to send the address , 1 tick for the read bit , 1 wait tick , and 16 ticks to fetch the data. the spi-like bus clock was 160MHz. So i was guaranteed to be able to do 1 transport within 1 bus cycle of the arm.  ) The processor picks up the data and goes on. The CPU is completely unaware that there was a bunch of stuff happening over a serial bus to fetch the data. The return path is one huge combinatorial address decoder that strips the data and returns what is needed directly into the bus format of the cpu. No need on the processor to do and-mask or-mask or shifting. (or things like sign extention or combining 2 registers into 1 variable ( 32 bit number split over 2 16 bit registers)

I also had a dma-like mechanism that would prevent the cpu having to wait for mulitple writes. The fpga would wait until it got a trigger that basically said : send all 'dirty' registers over. the cpu could then do other things.. IF it needed lockstepping those write operations used a different bus-cycle that guaranteed the data leaving before the cpu could execute its next instruction. The Arm-7 has 4 or 8 definable bus cycles and you can control what cycle is used for what memory range. so for data that always needed to leave before continuation you used a slower cycle.

That system has been in use since 2007 and everyone loves it. The generated verilog is'unreadable' by humans. but that is not required anyway.
Whenever you have peripheral blocks with large register sets , each containing multiple fields : abstract it. it is madness to try to code that by hand. it is mindnumbingly boring and if the register map changes during design you are royally screwed. good luck editing thousands and thousands of lines to relocate a variable or a field. The semiconductor design toolkits are full of 'generators'. feed a table and it generates the verilog for you.

Look at the design tools themselves. they come with macro wizards. i need this function. this is in , that is out, this is clock, that and this happens there and then. a is rising , b is falling, and z is asynchronous. . click a button and you end up with a thousand line verilog block. do you ever read that ? no. Would you ever craft that by hand from nothing ? no! that is madness.

I didn't invent this. This is standard practice. It's a macro generator for a very complex SPI-like device with hundreds of registers. It generates the hardware and the 'co-ware ( the arm-code) to interact with it in the , from a development perspective, shortest amount of time.
So what if the generated code is unreadable for humans and uses macros and many other things. you are not supposed to muck in that anyway. if it needs changing : use the top-level tool.

That being said : you can still exploit this by hand for smaller systems. make a 'human-like' language using macro definitions. That makes the flow of the state machine easier to understand than having to read through a bunch of syntax 'tree's that hides the forest. ( that what needs to be done ). I will craft the forest first. the Tree's are small macro's. IF my forest needs to change ( trees further apart, more pines than oaks , a narrower but longer forest ) i can do that in my 'forest description language'. That then gets 'translated' to tree instances.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1764
  • Country: us
Re: What HDL to start with
« Reply #78 on: April 03, 2020, 08:51:40 pm »
Maybe you should just give it a try; you'll pre surprised how much you can achieve with very little code. Usually I need at least 5 times less lines of code to achieve the same compared to the average VHDL out there.

Perhaps you should post an example of an average VHDL example and your 5x smaller code implementing the same example so we can see how you do it.
"That's not even wrong" -- Wolfgang Pauli
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27935
  • Country: nl
    • NCT Developments
Re: What HDL to start with
« Reply #79 on: April 03, 2020, 10:38:44 pm »
Maybe you should just give it a try; you'll pre surprised how much you can achieve with very little code. Usually I need at least 5 times less lines of code to achieve the same compared to the average VHDL out there.

Perhaps you should post an example of an average VHDL example and your 5x smaller code implementing the same example so we can see how you do it.
I already posted several examples. For example instantiating memory primitives instead of using a single line to declare an array. Another good example are address decoders and priority encoders. Google some examples; 9 out of 10 will have a line for each register or output combination. You can solve the first by using an array (together with meaningful constants which greatly enhance code readability if you like). The priority encoder can be written in a simple function with the added benefit that it will work for any bit length.
« Last Edit: April 03, 2020, 11:00:13 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27935
  • Country: nl
    • NCT Developments
Re: What HDL to start with
« Reply #80 on: April 03, 2020, 10:40:39 pm »
Macros, in this case, are obfuscators.

Nope. -sigh- This is always the case when trying to explain something on a forum... i try to give the minimum info so it would be clear what the intent is. But then it is misunderstood.
This has nothing to do with obfuscation, on the contrary. It is intended to make it easier to create state machines and logic that can sync up .

You make definitions for all kinds of events and items that need to happen at certain timestamps. in essence you are creating a language in which you describe the machine and what it does, what it waits for , how long , what it syncs with and so on.
But why invent a new language if a better language (SystemVerilog and VHDL) already exists? I think you just gave a perfect example of the limitations of Verilog and why people shouldn't start with it nowadays.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20627
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: What HDL to start with
« Reply #81 on: April 03, 2020, 10:58:14 pm »
Macros, in this case, are obfuscators.

Macros were a necessary evil back in the 70s an 80s with 64k address spaces. Now they are just evil.

One big problem they bring is that they screw up tools that parse the code for automated analysis, and require that the whole codebase has to (in effect) be compiled before a line can be analysed.

Another big problem is they also screw up the next person that looks a codebase. Personal little languages are a pain in the arse.

Languages have advanced since the 70s and have good mechanisms that achieve the same ends. Use 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
 
The following users thanked this post: nctnico, mrflibble

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9935
  • Country: us
Re: What HDL to start with
« Reply #82 on: April 04, 2020, 03:20:55 pm »

That being said : you can still exploit this by hand for smaller systems. make a 'human-like' language using macro definitions. That makes the flow of the state machine easier to understand than having to read through a bunch of syntax 'tree's that hides the forest. ( that what needs to be done ). I will craft the forest first. the Tree's are small macro's. IF my forest needs to change ( trees further apart, more pines than oaks , a narrower but longer forest ) i can do that in my 'forest description language'. That then gets 'translated' to tree instances.

The idea of creating an application specific "language" is certainly a valid use of macros.  I started playing with a macro assembler way back around 1970 and really got into the idea with the Digital Research Macro Assembler for CP/M.  It's really just a different way of looking at a problem.  Do I want to see something that reads closer to hardware or would I rather see something that reads closer to the application.

VHDL doesn't have macros so we use state names in the enums to provide context.  State variables can be simple integers but this doesn't provide much information.  So, we're going to use state names that are closer to the actions being taken.

It's pretty easy to dismiss macros and I'm pretty much in that camp but the idea of an application specific "language" is still a compelling use.

Alas, I use VHDL and have no intention of changing horses.


« Last Edit: April 04, 2020, 03:45:34 pm by rstofer »
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20627
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: What HDL to start with
« Reply #83 on: April 04, 2020, 03:37:31 pm »

That being said : you can still exploit this by hand for smaller systems. make a 'human-like' language using macro definitions. That makes the flow of the state machine easier to understand than having to read through a bunch of syntax 'tree's that hides the forest. ( that what needs to be done ). I will craft the forest first. the Tree's are small macro's. IF my forest needs to change ( trees further apart, more pines than oaks , a narrower but longer forest ) i can do that in my 'forest description language'. That then gets 'translated' to tree instances.

The idea of creating an application specific "language" is certainly a valid use of macros.  I started playing with a macro assembler way back around 1970 and really got into the idea with the Digital Research Macro Assembler for CP/M.  It's really just a different way of looking at a problem.  Do I want to see something that reads closer to hardware or would I rather see something that reads closer to the application.

VHDL doesn't have macros so we use state names in the enums to provide context.  State variables can be simple integers but this doesn't provide much information.  So, we're going to use state names that are closer to the actions being taken.

It's pretty easy to dismiss macros and I'm pretty much in that camp but the idea of an application specific "language" is still a compelling use.

Alas, I use VHDL and have no intention of changing horses.

DSLs are beguiling and have some benefits. But they have a lot of disadvantages when compared with alternative techniques like domain specific libraries.

DSLs always grow incrementally like a cancer, frequently until the creator doesn't understand all the interactions.

It can be difficult to get people willing to work in a DSL. Developers want to gain transferable skills, and DSLs aren't.

There is no tool support for DSLs. Either you spend time and money developing your own special purpose tools, or you are back in the early 80s using grep.

I one wrote a DSL. Fortunately I only spent a week on it before realising I should simply have used Forth (embedded tiny application).

I've seen a DSL scripting language take down a company.

Use standard language features and libraries in preference to going off in your own world.
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
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15326
  • Country: fr
Re: What HDL to start with
« Reply #84 on: April 04, 2020, 05:03:55 pm »
Macros, in this case, are obfuscators.

Macros were a necessary evil back in the 70s an 80s with 64k address spaces. Now they are just evil.

There is no real substitute when using C for a number of cases. In other languages, when there is, sure, use something more advanced.

One big problem they bring is that they screw up tools that parse the code for automated analysis, and require that the whole codebase has to (in effect) be compiled before a line can be analysed.

If the preprocessor is run before the analysis, they screw up nothing, and it's usually not hard to do especially when said tools have a CLI. Decent tools already do this on their own.
But they can make reading the output of the analysis more difficult, as they will deal with the expanded macros and not the macros themselves.

Another big problem is they also screw up the next person that looks a codebase. Personal little languages are a pain in the arse.

They may, or not. Depends on how consistent they are overall. It just takes reading their definition to understand them, as long as they are written in a logical manner. I know this is a very common argument against macros, but this has never really bothered me. Sure if the macros make no sense, it can be a pain to deal with. There's a good chance that if some developer can't write good macros, they can't write good code either, so that's often just the tip of the iceberg though IME.

If you still need to use macros, use them with a few rules. For instance, with C, my first rule for macros is to always define them in all uppercase, so you spot them immediately, and they can't be confused with any other identifiers or language keywords. Another rule: don't make them hide variables, so if they act on any variables, pass these as macro parameters only.

Languages have advanced since the 70s and have good mechanisms that achieve the same ends. Use them.

Some do, and when they do, I totally agree. But C, for instance, still doesn't really, and whatever you think of C, it's still widely used.

Now I admit we're talking about HDLs in this thread specifically, and for that, there is no contest, although Verilog still lacks a lot without macros compared to VHDL, and I'd agree you should probably switch to SystemVerilog if you're a Verilog user, but sometimes you just can't in a given project.
« Last Edit: April 04, 2020, 05:08:40 pm by SiliconWizard »
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20627
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: What HDL to start with
« Reply #85 on: April 04, 2020, 05:14:03 pm »
Macros, in this case, are obfuscators.

Macros were a necessary evil back in the 70s an 80s with 64k address spaces. Now they are just evil.

There is no real substitute when using C for a number of cases. In other languages, when there is, sure, use something more advanced.

One big problem they bring is that they screw up tools that parse the code for automated analysis, and require that the whole codebase has to (in effect) be compiled before a line can be analysed.

If the preprocessor is run before the analysis, they screw up nothing, and it's usually not hard to do especially when said tools have a CLI. Decent tools already do this on their own.
But they can make reading the output of the analysis more difficult, as they will deal with the expanded macros and not the macros themselves.

Precisely. And let's not think of C++ and templates :)

Quote
Another big problem is they also screw up the next person that looks a codebase. Personal little languages are a pain in the arse.

They may, or not. Depends on how consistent they are overall. It just takes reading their definition to understand them, as long as they are written in a logical manner. I know this is a very common argument against macros, but this has never really bothered me. Sure if the macros make no sense, it can be a pain to deal with. There's a good chance that if some developer can't write good macros, they can't write good code either, so that's often just the tip of the iceberg though IME.

For anything that has to last, or anything that is bigger than a half a dozen people, you will always have sub-optimum developers.

That can be true either because of simple probabilities, or because one developer's good style is another developer's incomprehensible mess.

Quote
Languages have advanced since the 70s and have good mechanisms that achieve the same ends. Use them.

Some do, and when they do, I totally agree. But C, for instance, still doesn't really, and whatever you think of C, it's still widely used.

it is horrifying that we are still writing very elaborate "COBOL" isn't it. I would have hoped for more advances in the last half century.

Quote
Now I admit we're talking about HDLs in this thread specifically, and for that, there is no contest, although Verilog still lacks a lot without macros compared to VHDL, and I'd agree you should probably switch to SystemVerilog if you're a Verilog user, but sometimes you just can't in a given project.

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

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9935
  • Country: us
Re: What HDL to start with
« Reply #86 on: April 04, 2020, 06:38:23 pm »
Even FORTRAN has advanced!  It is now called Fortran...

I like Fortran and use it every chance I get.  It is particularly useful for demonstrating things like the Riemann Sums for approximating integration or Euler's Method for solving differential equations.  I've been working with FORTRAN for more than 50 years!  Half a century!

Like VHDL, I started with FORTRAN and plan to use if forever.  These Johnny-Come-Lately languages like C++, Python, et al, won't have the staying power of FORTRAN.

It's a little bit newer (a year or so) but COBOL is still kicking around in the banking world.  Due to a scarcity of new programmers, I imagine the old-timers are paid very well.

 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20627
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: What HDL to start with
« Reply #87 on: April 04, 2020, 08:26:06 pm »
Indeed. Or at least to some extent, indeed.

But if C++ is the answer, you've asked the wrong question. Languages should be part of the solution (to your problem), not part of (an addition to your) problem.  FFI the C++ FQA (sic).

In that vein, I prefer languages that make me jump through hoops to express unambiguously what I need,  since that gives me the best chance of getting a working solution.
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 mark03

  • Frequent Contributor
  • **
  • Posts: 731
  • Country: us
Re: What HDL to start with
« Reply #88 on: April 04, 2020, 08:43:07 pm »
These Johnny-Come-Lately languages like C++, Python, et al, won't have the staying power of FORTRAN.

You forgot an smiley / wink emoji here, right?!

If not, don't worry:
Quote
Besides, the determined Real Programmer can write FORTRAN programs in any language.
https://web.mit.edu/humor/Computers/real.programmers
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15326
  • Country: fr
Re: What HDL to start with
« Reply #89 on: April 05, 2020, 12:25:50 am »
Even FORTRAN has advanced!  It is now called Fortran...

I like Fortran and use it every chance I get.  It is particularly useful for demonstrating things like the Riemann Sums for approximating integration or Euler's Method for solving differential equations.  I've been working with FORTRAN for more than 50 years!  Half a century!

Like VHDL, I started with FORTRAN and plan to use if forever.  These Johnny-Come-Lately languages like C++, Python, et al, won't have the staying power of FORTRAN.

It's a little bit newer (a year or so) but COBOL is still kicking around in the banking world.  Due to a scarcity of new programmers, I imagine the old-timers are paid very well.

Those are good examples. Or counter-examples might we say. Whereas many other newer languages can perfectly be used for the same applications, Fortran and Cobol were tailored for specific tasks, and it's often hard to beat that with monstrous general-purpose languages, however new, featureful and shiny they are.

As surprising as it may be, Cobol is actually still evolving; we can't consider it a dead language just used for legacy reasons. Its latest standard is from 2014 AFAIK!
« Last Edit: April 05, 2020, 12:28:26 am by SiliconWizard »
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9935
  • Country: us
Re: What HDL to start with
« Reply #90 on: April 05, 2020, 03:42:27 pm »
These Johnny-Come-Lately languages like C++, Python, et al, won't have the staying power of FORTRAN.

You forgot an smiley / wink emoji here, right?!
Probably...

The thing is, I'm sort of serious.  Fortran will never die and it has a huge headstart on these newer languages so they will never be able to catch up.
Quote


If not, don't worry:
Quote
Besides, the determined Real Programmer can write FORTRAN programs in any language.
https://web.mit.edu/humor/Computers/real.programmers

The more or less 'classic' FORTRAN examples I mentioned above can be written in any language and, for the most part, look amazingly similar at the source level.

In grad school, I had a project to create an 8080 Assembler using PL/I on an IBM 360/45.  Upon completion, my faculty advisor said I had succeeded in making PL/I look exactly like FORTRAN.

The original PL/M compiler for the 8080s was written Fortran but it certainly wasn't FORTRAN IV.  It seems to be a VAX dialect in use around 1980.
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: What HDL to start with
« Reply #91 on: April 05, 2020, 03:44:05 pm »
No problem. As nctnico added, if you use "macros" to define constants, sure there is some link with enumerations. But isn't there another mean of defining constants in Verilog than using macros? (Don't know enough of Verilog here...)
Well, there are the parameter and localparam keywords. For a more comprehensive overview of some of the uses and hideous abuses of Ye Olde Preprocessor, see for example this paper:
https://www.veripool.org/papers/Preproc_Good_Evil_SNUGBos10_paper.pdf

As for venturing past the Macro Mountains and entering yonder Dark DSL Forest, I pretty much subscribe to this:
Use standard language features and libraries in preference to going off in your own world.
Because yes, it seemed such a good idea at the time. And oh look at how big and unwieldy it has become. And lets not forget the ever popular cryptic error message caused by the inevitable "oh oops, I forgot that one crucial yet easy to overlook character in my macro call". Said error is of course reported as originating from file X, while the actual offender is located in some completely different file Y.

By sticking to the more established tooling you enjoy the benefits of support & updates available for said tooling. That in turn should mean the time cost of maintaining the tool chain is lower, when compared to rolling your own.

Coming back to the original question, put together a list of the various HDL revisions. Hopefully that provides the OP some help navigating the (sometimes confusing) HDL landscape.
That is, working under the rather optimistic assumption that said OP has not fled from the impromptu incarnation of our annual VHDL vs Verilog Flame-fest. ;)

As for Verilog vs SystemVerilog ... from the wiki page:

SystemVerilog is a superset of Verilog-2005, with many new features and capabilities to aid design verification and design modeling. As of 2009, the SystemVerilog and Verilog language standards were merged into SystemVerilog 2009 (IEEE Standard 1800-2009).

Out of curiousity I wanted to see if VHDL support in vivado was any better or worse than SystemVerilog. So googled for "xilinx vhdl-2019". Couple of relevant hits:

Oh look, people complaining about certain VHDL-2008 features still not being implemented. So, business as usual then! ;D Similar situation for SystemVerilog.
Incidentally, is there anyone out there using the mucho dinero synthesis tool$$$? Is the VHDL/SystemVerilog for synthesis support any better there? I would expect/hope "yes", but who knows? :-//
 
The following users thanked this post: oPossum

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15326
  • Country: fr
Re: What HDL to start with
« Reply #92 on: April 05, 2020, 03:56:04 pm »
Oh look, people complaining about certain VHDL-2008 features still not being implemented. So, business as usual then! ;D Similar situation for SystemVerilog.

Yes and not that surprising either. Look at how much time it took to get full compliance to C99 in C compilers, especially commercial ones. And the world of digital synthesis is yet a lot more conservative, and relatively slow to evolve.

New features of VHDL-2008 are nice, but not game-changing either. Many are just sugar coating. You can do without them while still having something pretty powerful at your disposal.
One of the most useful features of VHDL-2008 though IMO is generic packages. Before VHDL-2008, you had of course generic entities, but not generic packages. You'd sometimes find yourself wishing they existed, and was forced to use workarounds. So as long as generic packages are supported, I'm happy with the tools (and yes, even that I can do without, but it's just nice to have on occasion.)


 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 20627
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: What HDL to start with
« Reply #93 on: April 05, 2020, 05:20:15 pm »
Oh look, people complaining about certain VHDL-2008 features still not being implemented. So, business as usual then! ;D Similar situation for SystemVerilog.

Yes and not that surprising either. Look at how much time it took to get full compliance to C99 in C compilers, especially commercial ones.

Yes indeed. ISTR the triumphant announcement of the first complete C99 complier (or C++ something or other) about six years later. That was yet another confirmation that that toolset was as much part of the problem as part of the solution.

Mind you, things weren't necessarily better in the good old days: witness the plethora of compilers for subsets of Algol and Algol-68 languages.
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 mrflibble

  • Super Contributor
  • ***
  • Posts: 2051
  • Country: nl
Re: What HDL to start with
« Reply #94 on: April 07, 2020, 09:15:50 am »
Oh look, people complaining about certain VHDL-2008 features still not being implemented. So, business as usual then! ;D Similar situation for SystemVerilog.
Yes and not that surprising either. Look at how much time it took to get full compliance to C99 in C compilers, especially commercial ones. And the world of digital synthesis is yet a lot more conservative, and relatively slow to evolve.

New features of VHDL-2008 are nice, but not game-changing either. Many are just sugar coating. You can do without them while still having something pretty powerful at your disposal.
One of the most useful features of VHDL-2008 though IMO is generic packages. Before VHDL-2008, you had of course generic entities, but not generic packages. You'd sometimes find yourself wishing they existed, and was forced to use workarounds. So as long as generic packages are supported, I'm happy with the tools (and yes, even that I can do without, but it's just nice to have on occasion.)

It indeed did not come as a total surprise. ;D Especially Xilinx and Altera Intel are not particularly fast with implementing new language features. Definitely compared to companies that are more on the verification side of things like Mentor Graphics.

As for doing without the useful but not game-changing features, I've got mixed feelings there. Lets take for example port declaration. Sure, in Verilog-95 you can declare ports just fine, but the "new" Verilog-2001 syntax is more concise, and IMO helps readability. And to stick with the example of port declaration, in SystemVerilog you get interface and modport. Sure, you can get the interface functionality with a few macros to pack and unpack ports. Been there, done that. But I'd much rather use the real thing. Less custom code to maintain, plus more meaningful error messages when shit hits the fan. Also, no name mangling required while constructing constraint files. And something like modport, mmmmh, I don't think I would attempt cobbling that together with a few macros. I vaguely recall that VHDL has had the interface-like functionality for eons, but not sure about modport. Does VHDL have something similar to modport? I did a few searches but came up dry. But that could easily be because I don't know the proper VHDL related search terms...  :-//

Mind you, things weren't necessarily better in the good old days: witness the plethora of compilers for subsets of Algol and Algol-68 languages.
Keeping with C compilers, things were definitely not better in the good old days. I still remember the day when hunting down the actual error based on some loosely related error message was a skill on its own. Error message for line 1023? Aaaah, the error is here, on line 42 ... of a different file. With modern C compilers the error messages are spot on a lot more often. Someone finally spent some time on that "Parser must facilitate user-friendly warnings and error messages" TODO item.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15326
  • Country: fr
Re: What HDL to start with
« Reply #95 on: April 07, 2020, 02:28:20 pm »
As for doing without the useful but not game-changing features, I've got mixed feelings there. Lets take for example port declaration. Sure, in Verilog-95 you can declare ports just fine, but the "new" Verilog-2001 syntax is more concise, and IMO helps readability.(...)

Oh, I was specifically talking about VHDL-2008 vs. VHDL-2002 here. This was not meant as a general thought about new language features!

As to "modport", I don't know what it is. I've just taken a look at this: https://verificationguide.com/systemverilog/systemverilog-modport/
which was only moderately helpful. I'm under the impression we get the same thing with in/out/inout qualifiers in port declarations in VHDL, but I'm sure I'm missing the subtlety of "modport"...
« Last Edit: April 07, 2020, 02:30:43 pm by SiliconWizard »
 

Offline emece67

  • Frequent Contributor
  • **
  • !
  • Posts: 614
  • Country: 00
Re: What HDL to start with
« Reply #96 on: April 07, 2020, 02:54:57 pm »
.
« Last Edit: August 19, 2022, 03:47:03 pm by emece67 »
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15326
  • Country: fr
Re: What HDL to start with
« Reply #97 on: April 07, 2020, 05:16:27 pm »
In VHDL versions <2019 you can have ports of composite types. This allows you to use records as a kind of interfaces, but all members of a record used as a port (interface) must have the same directionality (in/out/inout). Some use such "interfaces" defining the directionality as inout, so both in and out members can be inside the interface.

VHDL-2019 raised such restriction and now the directionality of each member of a record used as a port can be explicitly declared. I think that this is, more or less, what modports do inside Verilog.

Ok, this is clear now.

I do use records in VHDL when implementing relatively "complex" designs, but I'm trying to think about the above and I'm questioning the benefit of directionality for each member. Whereas I can see when this would be useful, I'm not completely sure using record signals in that way would be a good idea design-wise. A bit undecided. But thanks for pointing out this new feature in VHDL-2019, I admit I haven't looked into it yet (and expect it to be implemented in commercial tools in like 10 years if we're lucky. ::) )
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27935
  • Country: nl
    • NCT Developments
Re: What HDL to start with
« Reply #98 on: April 07, 2020, 05:35:01 pm »
Record in VHDL are great to get a large number of related signals through several layers of a design. Saves a lot of typing and renaming if you want to add/delete/change a signal. I have used records as inout in the past but nowadays I use seperate in and out records.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15326
  • Country: fr
Re: What HDL to start with
« Reply #99 on: April 07, 2020, 05:39:13 pm »
Record in VHDL are great to get a large number of related signals through several layers of a design. Saves a lot of typing and renaming if you want to add/delete/change a signal.

Yes, and it just adds structure to your design.
But precisely - if each member can have a different directionality, manipulating the record as a whole in general becomes impossible. And IMO it would tend to add slopiness instead of improving things. So the idea of member directionality seems dubious to me, but that's just my opinion at the moment.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf