Verilog or VHDL?

[ehughes]

http://www.bawankule.com/verilogcenter/contest.html

In most real world scenarios, Verilog wins.

Verilog was created by 2 guys working in the industry to solve a real world problem.

VHDL was the result of government and academia trying to come up  with the end all modeling language.

Design by committee languages often end up ridiculously fluffed.

When it takes 3x the code to get the same functionality, VHDL ends up as an unreadable mess for large designs.

Once you get past FPGAs and move to ASICs, it is overwhelmingly Verilog (Cadence owns Verilog and is a huge player in the ASIC world)

[scatha]

http://www.bawankule.com/verilogcenter/contest.html

In most real world scenarios, Verilog wins.

Verilog was created by 2 guys working in the industry to solve a real world problem.

VHDL was the result of government and academia trying to come up  with the end all modeling language.

Design by committee languages often end up ridiculously fluffed.

When it takes 3x the code to get the same functionality, VHDL ends up as an unreadable mess for large designs.

Once you get past FPGAs and move to ASICs, it is overwhelmingly Verilog (Cadence owns Verilog and is a huge player in the ASIC world)

I don't see how that link constitutes a 'real world scenario' - it's from 1997 and based on a toy problem.

To claim a 3x overhead for VHDL is hyperbole - *maybe* if you were to maximise the number of small design units and then used the most verbose form of component instantiation, but in larger design units the LoC difference is small. I've certainly been subjected to more 'unreadable mess' Verilog projects than VHDL based-ones, to the point where I actively dread the language. Maybe things are different in ASIC land, but that's not a space I play in.

[nctnico]

http://www.bawankule.com/verilogcenter/contest.html

In most real world scenarios, Verilog wins.

If you think in logic and want to create a netlist then Verilog is the right tool. Verilog code looks exactly like a netlist to me. However I think I'd be done in 30 minutes to create the design requested by the contest with a few lines of VHDL and then tweak the synthesizer options to optimise the end result. VHDL versus Verilog starts to sound like an assembly versus C discussion.

[Cerebus]

VHDL versus Verilog starts to sound like an assembly versus C discussion.

Well, C and assembler are essentially the same thing. C is just an assembler that's non machine specific and somewhat less programmer hostile than most assemblers. No bounds checking (almost universal in other common HLLs at the time of C's inception), ability to freely switch between any interpretation of a string of bits as an integer or a pointer or a character, register variables, #define, #ifdef - classic macro assembler, the 'for' loop that looks like nothing more than an assembler macro etc. etc. To anybody who knows PDP-11 assembler (which was the original target for the K&R compiler) it's blindingly obvious where (++i) and (i++) came from - the C expression (a = *b++) compiles into a single instruction on a PDP-11; in fact I think even (*--a = *b++) would be a single instruction on a PDP-11 but honestly I'd have to check that particular expression.

C is, and always has been, a fancy assembler on steroids - that is its strength and its weakness.

[zapta]

When it comes to statemachines the first thing to do is to realise that you are making a statemachine. Too often you'll see code like 'if a=1 and b=5 then do X else if b=2 and c=2 then do Y' which is just a big stinking pile of unmaintainable sh*t.

Few years ago I needed to program a FPGA for the first time. When I shawn my initial code to a colleague with HDL experience, he gave me a good advice:  "avoid 'if' statements, use conditional expressions instead".

Something along these lines:

my_signal <= condition1 ? value1:
                     condition2 ? value2:
                     ...
                     default_value;

That made VHDL programming much easier for me, eliminating the complexity of multiple assignments per signal. This rule applied to all signals, not only state machines (where my_signal depends on itself).

[helius]

ability to freely switch between any interpretation of a string of bits as an integer or a pointer or a character

This violates the weak aliasing rule present in every version of ANSI and ISO C.

Qualifiers like const or restrict, variable-length arrays, and complex numbers, are also without any corresponding construct in assembly language.

These changes are part of a much wider shift in compiler technology, that means assembly programs are poorly optimized in comparison with compiled programs. A backward "assembler on steroids" is no longer relevant, and today's C doesn't fit that description. C programs that depend on being compiled into instructions just like they are written no longer work with today's compilers.

[Cerebus]

ability to freely switch between any interpretation of a string of bits as an integer or a pointer or a character

This violates the weak aliasing rule present in every version of ANSI and ISO C.

Still true though, vis:

Code: [Select]

void junk()
{
char *aBuffer;
unsigned long int aNumber;

aNumber = (unsigned long int) aBuffer;
aBuffer[0] = (char) aNumber;
}

That compiles in C99 without even a warning. A properly typed programming language wouldn't let me do that. An overgrown assembler would.

Qualifiers like const or restrict, variable-length arrays, and complex numbers, are also without any corresponding construct in assembly language.

These changes are part of a much wider shift in compiler technology, that means assembly programs are poorly optimized in comparison with compiled programs.

To be precise, those changes have nothing to do with compiler technology. They are changes in the language definition and could have easily been compiled with the same level of compiler technology as K&R C was. I'd strongly dispute your second assertion; with the exception of instruction sets that make extensive use of delay slots and similar hardware optimization techniques - a compiler will nearly always do a better job with those than a human.

A backward "assembler on steroids" is no longer relevant, and today's C doesn't fit that description.

Of course it's relevant, it's called embedded and systems programming. C is used for that because of its ability to get close enough to the hardware that twiddling bits in registers in predictable fashion.

 And of course modern C isn't an "assembler on steroids", it's an overgrown assembler on steroids. I'm messing with you here. C needed revising if it was going to continue to be used outside its original target environment but really it ought not have been and better programming languages ought to have become widespread instead.

C programs that depend on being compiled into instructions just like they are written no longer work with today's compilers.

I don't believe I said or implied anything like that. The nearness of the PDP-11 pre and post increment and decrement instructions and the C equivalents are just evidence of its quintessential nature, not an advocacy of that as a programming style. At any time with any compiler, any (non systems) code that depends on being compiled into particular explicit instructions should be immediately put into the bin.

My opinion stands. And it's just that, an opinion, but based on 40 years programming in literally dozens of different programming languages on dozens of different architectures. I've worked as a systems programmer ferreting about on the insides of operating systems and as a compiler writer writing code generators. My programming days pre-date the existence of C outside of the Bell Labs community. Prior to C, I spent many tedious hours writing assembler because there was no other way to get close enough to the hardware. Post C, I've been able to do those same tasks, sometimes quite portably, in C. That I have substituted C for assembler is pretty strong evidence of its basic nature.

[hamster_nz]

I am quite fond of C being so light-weight a language - and that you can build whatever you want on top of it's minimal library functions.

On big projects where issues slowly creep in I've added in my own safe-guards (like heap corruption detection, and data type verification) that disappears when _DEBUG isn't defined. It really isn't that hard - make a "safe_malloc(site_t size, unsigned data_type_magic)" that actually allocates a little more memory than needed and store a little metadata in the extra space.

You can then:
* verify that memory space hasn't been blown out - check the known value at the end
* verify that the pointer has been allocated to be the type expected - check the type value
* verify that you have allocated enough space - check the size value in the start
* verify that all allocated space gets free()ed

If you are really fussy you can have the C compiler include the file name and line number (have the preprocessor include __FILE__ and __LINE__ on the safe_malloc() call) so it can tell you where memory was allocated.

[mikeselectricstuff]

Still true though, vis:

Code: [Select]

void junk()
{
char *aBuffer;
unsigned long int aNumber;

aNumber = (unsigned long int) aBuffer;
aBuffer[0] = (char) aNumber;
}

That compiles in C99 without even a warning. A properly typed programming language wouldn't let me do that. An overgrown assembler would.

But the use of casting implies you know what you're doing - even the best-designed language can fail if people abuse it.
I'm sure it would have given warning is the casing wasn't there.

[nctnico]

Still true though, vis:

Code: [Select]

void junk()
{
char *aBuffer;
unsigned long int aNumber;

aNumber = (unsigned long int) aBuffer;
aBuffer[0] = (char) aNumber;
}
That compiles in C99 without even a warning. A properly typed programming language wouldn't let me do that. An overgrown assembler would.

But the use of casting implies you know what you're doing - even the best-designed language can fail if people abuse it.
I'm sure it would have given warning is the casing wasn't there.

Same here. Even in VHDL you can cast some types into another but without such a cast it won't 'compile'.

[Cerebus]

Can we get back on topic please? Y'know, Verilog, VHDL.

[Sal Ammoniac]

There is no alternative to saving state.  You can't build a sequential circuit without states.  The question is:  How do you code the FSM?  I use the two-process approach, one clocked process that simply updates the current state and the other is just an unclocked process that does all the work.

Yes, you need "memory" to build sequential circuits, but not always a full-blown state machine (with, for example, the two-process approach which you mention). Not everything is complex enough to require an FSM.

Here's an example: I recently implemented a simple serial port in Verilog, first as a full-blown state machine, and then as a much simpler non-FSM model.

Code: [Select]

`timescale 1ns / 1ps

module serial
  #(parameter TBIT=868,             // bit time in 100 MHz clocks for 115,200 baud
  )
  (
    input logic clk,
    input logic rst,
    input logic start,
    input logic [7:0] din,
    output logic [7:0] dout,
    output logic dataready,
    output logic txbusy,
    input logic RX,
    output logic TX
    );
   
  enum logic [2:0] {TXIDLE, TXSTARTBIT, SEND1, SEND2, TXSTOP} txstate, next_txstate;
  enum logic [2:0] {RXIDLE, RXSTARTBIT, RECEIVE1, RECEIVE2, RXSTOP} rxstate, next_rxstate;
  logic [11:0] txtimer, rxtimer;
  logic [7:0] data, data_next;
  logic [7:0] rdata, rdata_next;
  logic [3:0] bits, bits_next;
  logic [3:0] rbits, rbits_next;
  logic [11:0] txcount, rxcount;
  logic rx1, rx2;
 
  // Transmit
  always_ff @(posedge clk, posedge rst) begin
    if (rst) begin
      txcount <= 0;
      txstate <= TXIDLE;
    end
    else begin
      bits <= bits_next;
      data <= data_next;
      txcount <= txcount + 1;
      if (txcount >= txtimer) begin
        txstate <= next_txstate;
        txcount <= 0;
      end
    end
  end
 
  always_comb begin
    bits_next = bits;
    case (txstate)
      TXIDLE: begin
        txtimer = 1;
        data_next = din;
        TX = 1'b1;
        bits_next = 8;
        if (start == 1'b1)
          next_txstate = TXSTARTBIT;
        else
          next_txstate = TXIDLE;
      end
      TXSTARTBIT: begin
        txtimer = TBIT;
        data_next = din;
        TX = 1'b0;
        next_txstate = SEND1;
      end
      SEND1: begin
        data_next = data;
        TX = data[0];
        txtimer = TBIT;
        next_txstate = SEND2;
      end
      SEND2: begin
        txtimer = 0;
        TX = data[0];
        data_next = {1'b0, data[7:1]};
        bits_next = bits - 1;
        if (bits == 1) begin
          txtimer = 0;
          next_txstate = TXSTOP;
        end
        else begin
          next_txstate = SEND1;
        end
      end
      TXSTOP: begin
        TX = 1'b1;
        txtimer = TBIT;
        data_next = din;
        next_txstate = TXIDLE;
      end
      default: begin
        txtimer = 1;
        TX = 1'b1;
        data_next = din;
        next_txstate = TXIDLE;
      end
    endcase     
  end
 
  // Receive
  always_ff @(posedge clk, posedge rst) begin
    if (rst) begin
      rxcount <= 0;
      rdata <= 0;
      rxstate <= RXIDLE;
    end
    else begin
      rx1 <= RX;
      rx2 <= rx1;
      rbits <= rbits_next;
      rdata <= rdata_next;
      rxcount <= rxcount + 1;
      if (rxcount >= rxtimer) begin
        rxstate <= next_rxstate;
        rxcount <= 0;
      end
    end
  end
 
  always_comb begin
    rbits_next = rbits;
    rdata_next = rdata;
    case (rxstate)
      RXIDLE: begin
        rxtimer = 0;
        if (rx2 == 1'b0)                    // start bit
          next_rxstate = RXSTARTBIT;
        else
          next_rxstate = RXIDLE;         
      end
      RXSTARTBIT: begin
        rxtimer = TBIT/2 - 1;                   // 1/2 bit time
        rbits_next = 7;
        next_rxstate = RECEIVE1;
      end
      RECEIVE1: begin
        rxtimer = TBIT - 2;
        next_rxstate = RECEIVE2;
      end
      RECEIVE2: begin
        rxtimer = 0;
        rdata_next = {rx2, rdata[7:1]};
        rbits_next = rbits - 1;
        if (rbits == 0) begin
          rxtimer = 0;
          next_rxstate = RXSTOP;
        end
        else
          next_rxstate = RECEIVE1;
      end
      RXSTOP: begin
        rxtimer = TBIT - 2;
        next_rxstate = RXIDLE;
      end
      default: begin
        rxtimer = 1;
        next_rxstate = RXIDLE;
      end
    endcase
  end
 
  assign dout = rdata;
  assign dataready = (rxstate == RXSTOP);
  assign txbusy = (txstate != TXIDLE);
   
endmodule


Code: [Select]

`timescale 1ns / 1ps

module serial
  #(parameter TBIT=10               // bit time in 100 MHz clocks for 115,200 baud
  )
  (
    input logic clk,
    input logic rst,
    input logic start,
    input logic [7:0] din,
    output logic [7:0] dout,
    output logic dataready,
    output logic txbusy,
    input logic RX,
    output logic TX
    );
 
 
  // Transmit
  logic tx_started;
  logic [9:0] tdata; 
  logic [3:0] tbits = 0;
  logic [11:0] tcounter;
 
  always_ff @(posedge clk) begin
    if (start) begin
      tcounter <= TBIT - 1;
      tdata <= {1'b1, din, 1'b0};
      tbits <= 0;
      tx_started <= 1;
    end
    else if (tx_started) begin
      TX <= tdata[0];
      tcounter <= tcounter - 1;
      if (tcounter == 0) begin
        tcounter <= TBIT - 1;
        tbits <= tbits + 1;
        tdata = {1'b0, tdata[9:1]};
        if (tbits == 9)
          tx_started <= 0;
      end
    end
  end
 
  assign txbusy = tx_started;



  // Receive 
  logic rx_start;
  logic rx_started = 0;
  logic [7:0] rdata;
  logic [3:0] rbits = 0;
  logic [11:0] rcounter;
  logic [2:0] rxd = 3'b0;
 
  // synchronize to the incoming RX data line using a 3-bit shift register
  always_ff @(posedge clk) begin
    rxd <= {rxd[1:0], RX};
  end
 
  assign rx_posedge = (rxd[2:1] == 2'b01);              // positive edge on the RX line
  assign rx_negedge = (rxd[2:1] == 2'b10);              // negative edge on the RX line
  assign rx_start = (rx_negedge && ~rx_started);        // start bit detected
 
  always_ff @(posedge clk) begin
    if (rx_start) begin
      rcounter <= TBIT/2 - 1;
      rdata <= 8'b0;
      rbits <= 0;
      rx_started <= 1;
    end
    else if (rx_started) begin
      rcounter <= rcounter - 1;
      if (rcounter == 0) begin
        rdata <= {rxd[2], rdata[7:1]};
        rcounter <= TBIT - 1;
        rbits <= rbits + 1;
        if (rbits == 8)
          rx_started <= 0;
      end
    end
  end
 
  assign dout = rdata;
  assign dataready = ~rx_started;
   
endmodule


[nctnico]

Again: what often helps is to make a flowchart on paper first. This usually shows which states are irrelevant and/or can be combined.

[Kilrah]

I don't consider these being "making a state machine" or "not making a state machine", it's just different levels of optimization (more as source code amount than in resources) / expression of the same state machine.

Yes when you have to send 10 bits you can have an idle state and 10 "bitX" states, or you could only have one "running" flag and use a bit counter to know where you are... both are state machines just as much, they simply use a more or less explicit way to express it.

[Muxr]

My fulltime job is a programmer (distributed systems not embedded). When I got into FPGA for hobby purposes I looked at the syntax and liked Verilog better.. so I've been using Verilog 

[Sal Ammoniac]

I don't consider these being "making a state machine" or "not making a state machine", it's just different levels of optimization (more as source code amount than in resources) / expression of the same state machine.

Yes when you have to send 10 bits you can have an idle state and 10 "bitX" states, or you could only have one "running" flag and use a bit counter to know where you are... both are state machines just as much, they simply use a more or less explicit way to express it.

My point wasn't directed towards what you call these things, but that sometimes a more formal description of a problem is overkill and a simpler approach is not only more readable, but more likely to correct by inspection.

[legacy]

Code: [Select]

  type   state_t is
         (
         s_idle_w,
         s_idle_r,
         s_start_w,
         s_start_r,
         s_data0_w,
         s_data0_r,
         s_data1_w,
         s_data1_r,
         s_data2_w,
         s_data2_r,
         s_data3_w,
         s_data3_r,
         s_data4_w,
         s_data4_r,
         s_data5_w,
         s_data5_r,
         s_data6_w,
         s_data6_r,
         s_data7_w,
         s_data7_r,
         s_stop_w,
         s_stop_r
         );

well, on the psx_pad ... data_out is written on the falling edge
whereas the data_in is read on the rising edge

that means that, in the theory, you need both the edge types {falling edge, rising edge}
but you can't have both the logic on your fpga's project, you have to choose, it's mutually exclusive

personally i prefer "rising_edge", therefore I am using the following trick

Code: [Select]

  -- pad clock
  process(in_clock,in_reset,state_curr)
  begin
    if (in_reset = '1') then
       pad_out_clk  <= '1';
    elsif rising_edge(in_clock) then
       case state_curr is
          ------------------------------
          when s_data0_w =>
            pad_out_clk  <= '0';
          when s_data0_r =>
            pad_out_clk  <= '1';

_w stands for write data_out on falling edge
_r stands for read data_in on rising edge

therefore it actually reads date on rising edge, whereas it writes data on falling edge

Code: [Select]

constant tick         : integer := (clk_freq/baudrate);

the psx_pad's baudrate needs to be 250Khz, while clk_freq can be 50Mhz, so, since clk_freq < 2 * baudrate, the finite state machine can evolve its state_next at the *double speed* (that is the limitation of this method), and this permits to have the full control of both rising_edge and falling_edge (including delays)

Code: [Select]

  --fsm state_next
  process(in_clock,in_reset,state_curr)
  begin
    if (in_reset = '1') then
       state_next   <= s_idle_w;
    elsif rising_edge(in_clock) then
      if (tick_counter = tick-1) then
         case state_curr is
            ------------------------------
            when s_idle_w  =>
              state_next   <= s_idle_r;
            when s_idle_r  =>
              if (write_en = '1') then
                 state_next   <= s_start_w;
              else
                 state_next   <= s_idle_w;
              end if;
            ------------------------------
            when s_start_w =>
              state_next   <= s_start_r;
            when s_start_r =>
              state_next   <= s_data0_w;
            ------------------------------
            when s_data0_w =>
              state_next   <= s_data0_r;
            when s_data0_r =>
              state_next   <= s_data1_w;

it's not elegant and compact, it eats resources, but I am satisfied by the result 

[whollender]

you can't have both the logic on fpga, you can't have rising_edge and falling_edge
you have to choose, it's mutually exclusive: "rising_edge" is my best choice

You can actually use both, at least on Xilinx Spartan 6 using ISE 14.7.  I would assume that newer Xilinx devices also support both rising and falling edge clocks.  The only constraint is that all logic in a slice must use the same edge type, but you can use both on a single device.

[legacy]

The only constraint is that all logic in a slice must use the same edge type, but you can use both on a single device.

if all logic in a slice *MUST* use the same edge type it means you have to *choose the edge type*, and you can't use both types in your project, that is exactly what made me to think about the trick 

here I am on Spartan3E, ISE v10.1, and it claims errors if i try to do so (if i try to have both edge types in a single slice), whereas it's perfectly fine for ghdl, but ghdl doesn't have to fit to real hardware, therefore I can have both edge types only in RTL simulation.

[whollender]

if all logic in a slice *MUST* use the same edge type it means you have to *choose the edge type*, and you can't use both types in your project, that is exactly what made me to think about the trick 

here I am on Spartan3E, ISE v10.1, and it claims errors if i try to do so (if i try to have both edge types in a single slice), whereas it's perfectly fine for ghdl, but ghdl doesn't have to fit to real hardware, therefore I can have both edge types only in RTL simulation.

It does look like the Spartan3E CLBs are missing the inverter and mux on the clock input that the Spartan6 CLBs have.

On a Spartan6, code like this works just fine:

Code: [Select]

shift_in: process (BCLK)
begin
if rising_edge(BCLK) then
shiftreg_in <= shiftreg_in(shiftreg_in'high-1 downto 0) & I2S_DATA_IN;
end if;
end process;

shift_out: process (BCLK)
begin
if falling_edge(BCLK) then
if fs_str = '1' then
shiftreg_out <= data_reg_out;
else
shiftreg_out <= shiftreg_out(shiftreg_out'high-1 downto 0) & '0';
end if;
end if;
end process;

That way you don't absolutely need to have a double rate clock for doing that type of shift register work.

[Cerebus]

if all logic in a slice *MUST* use the same edge type it means you have to *choose the edge type*, and you can't use both types in your project, that is exactly what made me to think about the trick 

here I am on Spartan3E, ISE v10.1, and it claims errors if i try to do so (if i try to have both edge types in a single slice), whereas it's perfectly fine for ghdl, but ghdl doesn't have to fit to real hardware, therefore I can have both edge types only in RTL simulation.

It does look like the Spartan3E CLBs are missing the inverter and mux on the clock input that the Spartan6 CLBs have.

On a Spartan6, code like this works just fine:

Code: [Select]

shift_in: process (BCLK)
begin
if rising_edge(BCLK) then
shiftreg_in <= shiftreg_in(shiftreg_in'high-1 downto 0) & I2S_DATA_IN;
end if;
end process;

shift_out: process (BCLK)
begin
if falling_edge(BCLK) then
if fs_str = '1' then
shiftreg_out <= data_reg_out;
else
shiftreg_out <= shiftreg_out(shiftreg_out'high-1 downto 0) & '0';
end if;
end if;
end process;

That way you don't absolutely need to have a double rate clock for doing that type of shift register work.

I have vague memories from some years back of being forced to use a multiphasic clock on a Spartan 3 when I'd originally coded for using both clock edges. It was actually a blessing in disguise as I then came up with a much tidier design using 4 clock phases.

[Buriedcode]

Just implement something like enum/type for Verilog just for the sake of state machine.

Then you need to look at SystemVerilog. It implements many new features like this, while keeping syntax clean and simple.

Beat me to it.  State machines are much easier with it.

I can't say I have much experience (like 3 *working* projects?) but had to translate some VHDL to verilog and I realized that I can actually sit down and type verilog that makes sense to me - without having to stop every 5 minutes to google something - it makes sense, but as many have said, C-like yes, but of course - its a HDL, not software.

I had to learn VHDL at university, and I have used it here and there.  I don't like writing it at all, its an arse and takes *me* a long time to write any module.  But the plus is, once the design software stops pointing out errors - it generally works exactly as intended.  Where-as verilog, I usually have to verify with a logic analyzer and seemingly endeless simulations, even then it often doesn't do what I intended first time. So really both have their place, for reliability and if you were going to do it for a job, I would learn VHDL (having to actually do that now..).

[legacy]

even if I can use a spartan6 board like the papilio/pro, I have legacy reasons to support spartam3e boards,

using both clock edges seems a blessing in disguise (a false blessing), especially if the playstation's pad uses a long cable (~half meters between the pad and the controller), spi doesn't work well with long cables, and you come into troubles if you don't provide extra sample & hold 






in the simulation the fpga clock is 50Mhz, the psx_pad clock is 12.5MHz
note the delay between psx_pad's clock and psx_pad's cmd (data out)

[legacy]

main reasons to use vhdl: tools!

I don't feel comfortable with verilog's tools, whereas ghdl has offered the opportunity to develop the following building tool, it's written in C under linux, it's a project I have developed to boost my productivity, and it's fine

Code: [Select]

# cat project.list.myprj
../../rtl/package
../../rtl/bus-mm
../../rtl/bus-mm-controller-sram-asynchronous
../../rtl/controller-sram-asynchronous
./
define sources

Code: [Select]

# cat project.analysis.myprj
measure bus_clock
time_lapse dtack
define what you want to observe from the RTL simulation

Code: [Select]

# cat project.time.myprj
100us
define simulation time

Code: [Select]

# myghdl-build-project-makefile-v6
once all of the above has been defined,  the tool automatically builds the Makefile

Code: [Select]

# myghdl-build-project-makefile-v6
[*] ../../rtl/package
[*] ../../rtl/bus-mm
    [[bus_mm_alignment.interface]]
    bus_mm_alignment
    [bus_mm.def]
    [[bus_mm_device.interface]]
    [[bus_mm_device_sel.interface]]
    bus_mm_device_sel
    bus_mm_device
    [[bus_mm.interface]]
    [[bus_mm_size_mask.interface]]
    bus_mm_size_mask
    bus_mm
    stage_load_store
[*] ../../rtl/bus-mm-controller-sram-asynchronous
    [[bus_mm_controller_sram_asynchronous.interface]]
    bus_mm_controller_sram_asynchronous
[*] ../../rtl/controller-sram-asynchronous
    [[controller_sram_asynchronous.interface]]
    controller_sram_asynchronous
[*] ./
    tb_my
#
packages are handled as "definitions", components are handled as "interfaces", everything else is handled as "behavioral implementation", this tool is able to resolve the dependency tree, in order to allow to compile without errors. ghdl needs some external work, whereas Xilinx ISE is also able to do the same without any external help, I like ISE, I don't like iSim

Code: [Select]

co-nix arise-v2-bus-mm # make
compiling bus_mm.def ... done
compiling controller_sram_asynchronous.def ... done
compiling +definitions ... done
compiling bus_mm_alignment.interface ... done
compiling bus_mm_device.interface ... done
compiling bus_mm_device_sel.interface ... done
compiling bus_mm.interface.interface ... done
compiling bus_mm_size_mask.interface ... done
compiling controller_sram_asynchronous.interface ... done
compiling stage_load_store.interface ... done
compiling +interfaces ... done
compiling bus_mm_alignment ... done
compiling bus_mm_controller_sram_asynchronous ... done
compiling bus_mm_device_sel ... done
compiling bus_mm_device ... done
compiling bus_mm_size_mask ... done
compiling bus_mm ... done
compiling stage_load_store ... done
compiling controller_sram_asynchronous ... done
compiling tb_my ... done
compiling +behaviorals ... done
running simulation ... done, see report.txt
running analysis ... done, see analysis.txt
a gtkwave file (tbencha.ghw) is now available with time details, while analysis.txt contains a lot of useful information, e.g. time/frequency report

Code: [Select]

..
bus_clock: 40000000 fs, 25000000 Hz
dtack: 120000000 fs
..


Code: [Select]

# make view
it launches gtkview

also I am using this vhdl-helper, it's a collection of useful functions which help me a lot with the test bench activity 


I don't yet have a similar ecosystem (tools and helpers) with verilog, not yet 

edit:
I have also developed other tools which help me to create the test-bench and interfaces, it partially understands vhdl, the parser doesn't understand the whole vhdl grammar, just a subset, anyway it's enough to extract entities, build components, etc etc. it's not like Sigase, but it's fine for me, and it doesn't cost a license.

[nctnico]

I use the Eclipse and the (free) veditor plugin to write VHDL because it is 1000 times better than the crummy editor in ISE. Veditor is not perfect yet when it comes to cross referencing type declarations and syntax checking but it already makes life a whole lot easier.