What is a better write enable

[pcprogrammer]

I'm making a micro controller interface with a FPGA and like to make it synchronous with the internal FPGA clock to be able to write different registers within the design.

Found synchronization code with a shift register and that works in the simulator where it shows a one internal clock period long pulse on the intended edge of the external pulse. When I follow BrianHG his advise to basically always use the posedge of the main clock the pulse starts on the rising edge of this clock and also ends on the rising edge. Is this good for enabling the write of a register or is it better when the pulse starts and ends on the falling edge of the main clock, having the enable active for sure on the rising edge of the clock.

Code for the pulse starting and ending on the rising edge

Code: [Select]

  //---------------------------------------------------------------------------
  //Synchronize to fpga clock system

  reg mcu_clk0 = 0;
  reg mcu_clk1 = 0;
  reg mcu_clk2 = 0;
  reg mcu_enable = 0;

  //Sample the mcu clock input on the up going edge of the main clock
  always@(posedge i_main_clk)
    begin
      mcu_clk2 <= mcu_clk1;
      mcu_clk1 <= mcu_clk0;
      mcu_clk0 <= i_clk;

      mcu_enable <= !mcu_clk1 & (mcu_clk2 ^ mcu_clk1);  //Only enable on the falling edge of the external clock
    end

Code for the pulse starting and ending on the falling edge

Code: [Select]

  //---------------------------------------------------------------------------
  //Synchronize to fpga clock system

  reg mcu_clk0 = 0;
  reg mcu_clk1 = 0;
  reg mcu_clk2 = 0;
  reg mcu_enable = 0;

  //Sample the mcu clock input on the up going edge of the main clock
  always@(negedge i_main_clk)
    begin
      mcu_clk2 <= mcu_clk1;
      mcu_clk1 <= mcu_clk0;
      mcu_clk0 <= i_clk;

      mcu_enable <= !mcu_clk1 & (mcu_clk2 ^ mcu_clk1);  //Only enable on the falling edge of the external clock
    end

The only difference is the edge of the clock being used to make the pulse, which for the second is against the advice of BrianHG. When the second is better timing wise but bad for clock performance is there a better way of coding it to get the same result?

The first screen capture shows the pulse starting and ending on the rising edge. The second one shows it starting and ending on the falling edge.

[BrianHG]

It depends on how your MCU output drives the FPGA.

Are you using a bit-bang approach to driving the MCU IOs?
Are you using an MCU's dedicated UART IO, or SPI/I2C port?

If your MCU UART is fast, like if it can achieve megabaud rates, it would actually be easiest to just use my Verilog UART and snap a string command line.  (This also makes interfacing with things like RPI as their library already contains HW UART commands.)  If you only need a single megabaud, again using a UART interface means just hooking the same IO and code to a USB-RS232 adapter and you can command your unit from a PC or MCU alike as well as have a status return channel.  A simple 1 wire, or 2 wire for bidirectional interface.

[pcprogrammer]

The MCU interface is bit banged IO. It is an Allwinner F1C100s. Have not measured the write pulse yet, but had some code working that was made for the FNIRSI 1013D scope. The problem with that is that the register writing is not done with the main clock, but with a to the main clock synchronized clock, which I like to change to this write enable setup.

Edit: It is an 8 bit parallel  interface with a read/write signal and a data/command signal.

[BrianHG]

An easy bitbang approach is the same as my other thread's:

Code: [Select]

always @(posedge clk_125) begin
clk_half <= !clk_half ; // Generate a 62.5MHz clock in phase with the 125MHz dac data.
endwhich is already super close to your current setup.

I'm assuming you want a parallel data buss input with multiple words for super speed, plus the enable.

example (Excuse my HDL shorthand):

Code: [Select]

input         clk_125mhz,
input         data_clock,
input         data_packet_ready,
input [7:0] data_in_bus,

output  reg [xx:0] ctl_1,
output  reg [xx:0] ctl_2

reg [7:0] cmd_packet [0:2];  // A store of a string of bytes which will be our command.

reg prev_data_clock = 0;

always @(posedge clk_125mhz) begin

prev_data_clock <=  data_clock ;

  if (prev_data_clock != data_clock ) begin // D-Latch and shift hold the last 3 transmitted bytes every time the data_clock  toggles
      cmd_packet [0] <= data_in_bus ;
      cmd_packet [1] <= cmd_packet [0] ;
      cmd_packet [2] <= cmd_packet [1] ;
  end

  if (data_packet_ready) begin // when the data packet is ready, check if the command drives any controls and latch them through in a clean single shot.
     if (cmd_packet [0]==8'h01) begin
                                   ctl_1[7:0]  <= cmd_packet[1];
                                   ctl_1[15:8] <= cmd_packet[2];
                                             end
     if (cmd_packet [0]==8'h02) begin
                                   ctl_2[7:0]  <= cmd_packet[1];
                                   ctl_2[15:8] <= cmd_packet[2];
                                             end

  end

end

Is this something like what you want to do?

[BrianHG]

When bitbanging for the above code, just:

Make sure the 'data_packet_ready' is clear.
TX Byte 1 on the 'data_in_bus'.
Invert the 'data_clock'
TX Byte 2 on the 'data_in_bus'.
Invert the 'data_clock'
TX Byte 3 on the 'data_in_bus'.
Invert the 'data_clock'
Set the 'data_packet_ready'.
Clear the 'data_packet_ready'.

So long as your MCU doesn't exceed 75MHz on the data transmision, you should capture clean data.

Note that you can expand the 'reg [7:0] cmd_packet [0:2]' size to 5 bytes, or make it 16bits wide depending on how you transmit your data bus.

You can even shrink the cmd_packet to 2 and have an 8 bit address and 8 bit data bus.

[BrianHG]

Sorry, didn't take into account the 'read back' function.
And if you only need an 8bit address with 1 8 bit data going at a time, you can further simplify my code and use 1 wire to transmit data and 1 wire to select read instead of write.

[BrianHG]

Example:

Code: [Select]

input         clk_125mhz,
input         data_clock,
input         data_readback,
inout [7:0] data_bus,

input         [7:0] rctl_1,
input         [7:0] rctl_2,
output  reg [7:0] wctl_1,
output  reg [7:0] wctl_2

reg [7:0] address;  // A store of a string of bytes which will be our command.
reg oe_data = 0;
red [7:0[ data_out = 0;

assign data_bus = oe_data ? data_out : 8'bzzzzzzzz ; // Generate the bi-directional 8bit IO port.

reg prev_data_clock = 0;

always @(posedge clk_125mhz) begin

prev_data_clock <=  data_clock ;

  if (!prev_data_clock && data_clock ) begin // Load address on the detected rising transition of the data_clock.
      address <= data_in_bus ;
  end

  if (prev_data_clock && !data_clock ) begin // Load data on the detected falling transition of the data_clock.
       if (address = 8'h01) wctl_1<=data_bus;
       if (address = 8'h02) wctl_2<=data_bus;
  end

// readback control

if (data_readback && data_clock ) begin // When the data_readback is high and only while the data_clock is kept high.

   oe_data <=1 ; // output enable 8 bit bus.

       if (address = 8'h81) data_out <= rctl_1 ;
       if (address = 8'h82) data_out <= rctl_2 ;


end else  oe_data <=0 ; // input enable 8 bit bus.

end

This code is missing a 'reset' at the beginning and you may add a check for output enable by looking at the stored high address bits to help protect your IOs.

To transmit data:

Make sure the 'data_clock' & 'data_readback' are low.
output enable the MCU 8bit data port
TX Address on the 'data_bus'.
Make 'data_clock' high
TX Control byte on the 'data_bus'.
Make 'data_clock' low.
Done. 

To read data:
Make sure the 'data_clock' & 'data_readback' are low.
output enable the MCU 8bit data port
TX Address on the 'data_bus'.
Make 'data_clock' high
Switch your MCU 8-bit bus to input mode and then make 'data_readback' high.
wait 1 nop
read 8 bit data bus.  (You can pause here, or continuously read here if you want to monitor a time sensitive status flag)
Make the 'data_clock' & 'data_readback' low.
Done. 

[BrianHG]

Now, if you were using SystemVerilog instead of Verilog, we could have made the 'wctl' out an 8 bit array with 256 words where any of your other modules could tap a byte or multiple bytes within.

Same for the read bus.


Example change:

Code: [Select]

if (prev_data_clock && !data_clock ) begin // Load data on the detected falling transition of the data_clock.
       if (address = 8'h01) wctl_1<=data_bus;
       if (address = 8'h02) wctl_2<=data_bus;
  end

Would change to:

Code: [Select]

if (prev_data_clock && !data_clock ) begin // Load data on the detected falling transition of the data_clock.
       wctl[address]<=data_bus;
  end

and at the top, a single:

output  logic [7:0] wctl [0:255]

[pcprogrammer]

Wow BrianHG you have been busy Thank you for all the input.

Lots of stuff to look into, and novel idea's on how to do a thing like this.

The software side of the FNIRSI uses a single byte command written to the FPGA first and then dependent on the command 1 to 4 data bytes can either be written or read. For the sample data it allows the successively reading of the samples after the command for it has been written. Forum member morris6 made a new implementation for the FPGA of the scope, but the reversed code would need several modifications for working with it and I did not had the drive anymore to continue with that project.

So I moved on to this AWG project. The idea is to be able to control two channels with a separate step setting for both the negative and the positive portion of the signal giving the ability to do "pulse width" modulation on every type of signal. This means 4x 48bits of step data. Also setting the phase needs to be able, so another 2x 48bits. An option to reset the channels phase registers, which can just be a command without data.

Especially the writing of the phase data needs to be synchronized with the 125MHz clock since it has to be loaded into the actual signal_phase registers.

I have to play with your ideas to see how that can work.

The project will end up in my lichee nano repository. The hardware portion is already there: https://github.com/pecostm32/Lichee_Nano

[BrianHG]

Setup all your regs with my second code.
Once done, make a single address which will allow you to snap the block of regs all at once.

IE: in system verilog:

Code: [Select]

if (wctl[0][127] && any_other_event_you_like)  all_at_once_wctl[0:255] <= wctl[0:255] ;

and add at the top:

output  logic [7:0] wctl [0:255],
output  logic [7:0] all_at_once_wctl [0:255]

Now, just make sure address 127 = 0.
Set all your regs.  This will progressively fill all of wctl[0:90] bytes or so...
Now, set address 127 = 1.  Now, in a single 125mhz clock, all of the 'all_at_once_wctl' will simultaneously change to the slowly filled 'wctl'.

You can also make a separate input called ' any_other_event_you_like' from the MCU or from counter and timers from your synthesizer to do the same thing.

[BrianHG]

My first example code was better suited to be used as an auto-address or multi-byte command with 1 address.

My second code is a direct addressing for each byte.

Depending on the instruction set of your MCU, method #1 might save 1-2 additional clock cycles per byte in a multi-byte command.  So, sending 4 bytes may save 3-6 MCU clocks VS my simpler version #2 where you need to stuff an address before each byte.

[pcprogrammer]

example (Excuse my HDL shorthand):

Code: [Select]

input         clk_125mhz,
input         data_clock,
input         data_packet_ready,
input [7:0] data_in_bus,

output  reg [xx:0] ctl_1,
output  reg [xx:0] ctl_2

reg [7:0] cmd_packet [0:2];  // A store of a string of bytes which will be our command.

reg prev_data_clock = 0;

always @(posedge clk_125mhz) begin

prev_data_clock <=  data_clock ;

  if (prev_data_clock != data_clock ) begin // D-Latch and shift hold the last 3 transmitted bytes every time the data_clock  toggles
      cmd_packet [0] <= data_in_bus ;
      cmd_packet [1] <= cmd_packet [0] ;
      cmd_packet [2] <= cmd_packet [1] ;
  end

  if (data_packet_ready) begin // when the data packet is ready, check if the command drives any controls and latch them through in a clean single shot.
     if (cmd_packet [0]==8'h01) begin
                                   ctl_1[7:0]  <= cmd_packet[1];
                                   ctl_1[15:8] <= cmd_packet[2];
                                             end
     if (cmd_packet [0]==8'h02) begin
                                   ctl_2[7:0]  <= cmd_packet[1];
                                   ctl_2[15:8] <= cmd_packet[2];
                                             end

  end

end


As a programmer the construct above feels counter intuitive I have to get used to another way of thinking, more parallel and less sequential.

The "prev_data_clock <=  data_clock;" before the "if(prev_data_clock != data_clock)" looks impossible. Assigning the signals to become the same and at the same time check that they are not

I do like the concept of having the MCU tell the FPGA that a transfer is done. This way there is no need for a counter to keep track of the bytes coming from the MCU and it gives a clean point in time for the FPGA to transfer the data to the intended register.

Also have to look at verilog modules differently then how I would build hardware with TTL logic. I was thinking of a data/address bus setup with control signals between the modules to transfer the data to the registers, instead of lots of wires between the modules. But since it is all compiled it does not matter if there is a big wire list between the main and the sub modules.

My way back experience with FPGA was making schematics in Orcad and then use XACT to turn them into a bitstream. Way different then with HDL.

[BrianHG]

Also have to look at verilog modules differently then how I would build hardware with TTL logic.

Note that what's illustrated here is still like TTL logic gates.

Think of each 'cmd_packet' as a 74LS574, data in from MCU to the first one, then data out of that one to the next 74LS574.

All 3 CLK ins of the 8bit parallel D-Flipflops 74LS574 are all tied to this logic:

(clk_125m && (prev_data_clock != data_clock))

This will pulse true when the 125m goes high and you input 'data_clock' just switched high or low compared to what it's value was 1 clk_125m ago.

Think of the cmd_packet in this example as a command line buffer and once the 'data_packet_ready' goes high, we look at the final cmd_packet[0] and decide what to do with the contents of the contents of the parallel byte shift in buffer snapping everything in a single 125MHz clock.

My code here minimizes toggles on your MCU's output port and operates so that you set the MCU data, then the data_clock guaranteeing that the data going into the FPGA is ready and clean before the capture takes place as long as your MCU isn't toggling the port above 125MHz.  Well, I guess you can run this section on the 250MHz clock if you like.  You would have a damn fast capable 8bit IO port.

[BrianHG]

Also, remember, if you used huge 64bit x 128 arrays called example:

Code: [Select]

output reg [63:0] settings [0:127]
using system verilog allowing array ports feature,  you should be able to tie to your other modules the single array address you like as your settings making everything a single net name with a single address.

Any unused signal wires in the array net is automatically removed/pruned by the FPGA compiler during compile time, so those resources never tied to anything wont ever be used as logic cells in the FPGA.

[pcprogrammer]

I know it is still like TTL logic and understand the concept. I was just pointing out that there is a difference in how things are done in the different languages. (Seeing TTL as a language)

Making a thing like this with TTL in schematic form would be easiest with an 8 bit data bus and some control signals. In verilog the connections between the modules could be done in the same way, but I think it is more complicated then just listing the needed registers in the module signal list, and handle all the transfers in the MCU interface module.

The MCU won't reach that high speeds. At max I think 2MB/s or so. SPI would be faster. I think it can reach 100Mb/s but doubt it will be reliable at that speed.

I do have another issue. I went from a flat design to a modular design with separate files for the different parts of the system. For the MCU interface this means having an inout [7:0] io_data signal for the connection with the IO pins. In the main module this is also in the signal list as a wire. (inout wire [7:0] io_mcu_d) In the main module these are connected to each other in the declaration of the MCU interface module. (    .io_data (io_mcu_d),)

On compile the system failed with an error that it could not maintain the Hiz this way and that the hierarchy should be flat. I added (*keep_hierarchy = "no"*) to the MCU interface module and that fixed it.

Is there another way of doing this?

[pcprogrammer]

Also, remember, if you used huge 64bit x 128 arrays called example:

Code: [Select]

output reg [63:0] settings [0:127]
using system verilog allowing array ports feature,  you should be able to tie to your other modules the single array address you like as your settings making everything a single net name with a single address.

Any unused signal wires in the array net is automatically removed/pruned by the FPGA compiler during compile time, so those resources never tied to anything wont ever be used as logic cells in the FPGA.

Since the whole HDL stuff is new to me, I like to focus on getting a grasp on standard verilog first.

Not sure about what the implication of the system verilog setup is on the MCU side. Is it still possible to write just data for a single register (single or multi byte) and activate that with a last write or do all the bytes have to be written every time?

[BrianHG]

Hmm, in Quartus,  I have the top-hierarchy where everything is connected to the io pins:

inout [7:0] io_data,

in my sub-modules, I have the same at every level.

I have never used:

inout wire [7:0] xxx_wire,

I would just place the:

.io_data (io_data),

when initiating the sub module.  The compiler knows that the . in front of the same net name means it's a port name inside the sub module while using the same of a different net should connect the 2.

Unless you wrote something different.

[BrianHG]

SystemVerilog is backwards compatible with Verilog.
You just save your files with a .sv instead of a .v.

System verilog just expands the lexicon and features.
It has a better handle when using negative / signed numbers.
It can better handle regs with arrays, or memories.
It has an improved 'combinational' logic capabilities.  (Immediate static logic, no clock)

It has a lot more simulation test bench functions.

[pcprogrammer]

Hmm, in Quartus,  I have the top-hierarchy where everything is connected to the io pins:

inout [7:0] io_data,

in my sub-modules, I have the same at every level.

I have never used:

inout wire [7:0] xxx_wire,

I would just place the:

.io_data (io_data),

when initiating the sub module.  The compiler knows that the . in front of the same net name means it's a port name inside the sub module while using the same of a different net should connect the 2.

Unless you wrote something different.

Strange thing in the Tang IDE then.

It does compile but I get this warnings.

Code: [Select]

SYN-5045 WARNING: Netlist check -- multi-inout net has non-mpin inout pin mcu.io_data[7].
SYN-5036 WARNING: Tri-buffer 'u2' can't be implemented by pad. Please flatten model 'mcu_interface' by adding directive 'synthesis keep_hierarchy'.

Did not test the result in the actual hardware.

Does not make a difference if there is wire in the main module signal list or not.

Probably not a big deal and it is fixed with the (*keep_hierarchy = "no"*) directive. Was just wondering about it.

[BrianHG]

On compile the system failed with an error that it could not maintain the Hiz this way and that the hierarchy should be flat. I added (*keep_hierarchy = "no"*) to the MCU interface module and that fixed it.

Is there another way of doing this?

Perhaps this is not a coding problem with the inout and inout wire, maybe the way you set your hierarchy order in your FPGA compiler setup is incorrect.

The module with the connections to the IO pins should be set to the 'top hierarchy'.
Inside that HDL module, you should be initiating all you sub modules, including the MCU interface module, and wiring them to the IO pins as well as together.  These modules should be below that top module.  If you have the order wrong, then yes, there may be a problem with you 8bit MCU interface trying to drive a tristate 8'bzzzzzzzz into a module beneath it instead of above.

[pcprogrammer]

By the looks of the project navigation the hierarchy should be in order.

The compiler just wants it to be flat to get it correct.

There is an actual difference in the number of configuration bits used, so the hardware will be different.

[BrianHG]

It does compile but I get this warnings.

Code: [Select]

SYN-5045 WARNING: Netlist check -- multi-inout net has non-mpin inout pin mcu.io_data[7].
SYN-5036 WARNING: Tri-buffer 'u2' can't be implemented by pad. Please flatten model 'mcu_interface' by adding directive 'synthesis keep_hierarchy'.

Did not test the result in the actual hardware.

Does not make a difference if there is wire in the main module signal list or not.

Probably not a big deal and it is fixed with the (*keep_hierarchy = "no"*) directive. Was just wondering about it.

Adding the directive 'synthesis keep_hierarchy' to the MCU module should then do it.

I'm not sure, but using that directive tells the compiler to follow / generate the hierarchy order the way in which you wrote the code instead of the way you have the modules listed with the top module and it's siblings in the compiler setup.

At least, in Quartus and Lattice Diamond, we tell the compile in it's settings menu which source file is the top hierarchy and which source files are it's children.  Otherwise, those compilers will also get confused.

[BrianHG]

By the looks of the project navigation the hierarchy should be in order.

The compiler just wants it to be flat to get it correct.

There is an actual difference in the number of configuration bits used, so the hardware will be different.

Wrong code, I need to see the wiring in you top hierarchy.

[pcprogrammer]

I tried using that directive 'synthesis keep_hierarchy' but it did not work. Google search gave me the (*keep_hierarchy = "xxx"*). Tried it with yes and no dice, but with no it solved it.

Have to look into if there are compiler settings to make things behave differently.

[pcprogrammer]

By the looks of the project navigation the hierarchy should be in order.

The compiler just wants it to be flat to get it correct.

There is an actual difference in the number of configuration bits used, so the hardware will be different.

Wrong code, I need to see the wiring in you top hierarchy.

Attached it the whole project.