OK HOST - bus interfacing - vhdl vs verilog - different implementation - question

VHDL / Verilog Discussion
1

Ok so I predominantly come from an extensive VHDL background, yet im trying to understand the syntax in the OKHost verilog samples (shown below)

– begin

[COLOR="#FF0000"]wire [65*3-1:0] okEHx; // (195-1) : 0 [/COLOR]
okHost okHI(
.okUH(okUH),
.okHU(okHU),
.okUHU(okUHU),
.okAA(okAA),
.okClk(),
.okHE(okHE),
.okEH(okEH)
);

[COLOR="#FF0000"]okWireOR # (.N(3)) wireOR (okEH, okEHx); // 3[/COLOR]

okWireIn wi00(.okHE(okHE), .ep_addr(8’h00), .ep_dataout(ep00wire));
okWireOut wo20(.okHE(okHE), .okEH([COLOR="#FF0000"]okEHx 065 +: 65 ][/COLOR]), .ep_addr(8’h20), .ep_datain(ep20wire)); [COLOR="#FF0000"] /// what is 065 +: 65 and how does it translate[/COLOR]
okWireOut wo22(.okHE(okHE), .okEH([COLOR="#FF0000"]okEHx 165 +: 65 ][/COLOR]), .ep_addr(8’h22), .ep_datain(ep22wire));
okTriggerIn ti40(.okHE(okHE), .ep_addr(8’h40), .ep_clk(sys_clk), .ep_trigger(ep40wire));
okTriggerOut to60(.okHE(okHE), .okEH(okEHx 265 +: 65 ]), .ep_addr(8’h60), .ep_clk(sys_clk), .ep_trigger(ep60trig));

[COLOR="#FF0000"]// what /how does okEH(okEHx 2*65 +: 65 ]) work?? [/COLOR]

– end

I tried making the code a bit more understandable, but my implementation for some reason seems to have an issue - when using frontpanel components - it looks like the signals are getting crossed somehow :
it synthesizes, and all but when tying a counter to endpoint 0x22 i sometimes see the data on endpoint 0x20 - and so my front panel xml gui gets all weird. and im not a fan of super convoluted verilog statements - and dont understand how the default code (above) works with its " N*65 +: 65 " code

this code below makes more sense to me but doesnt seem to work right – [COLOR="#0000CD"]and im trying to figure out WHY[/COLOR] :

– begin
parameter OK_endpoints = 3;

[COLOR="#FF0000"]wire (65OK_endpoints)-1:0] okEHx; // (365)-1 : 0 => (195 -1) : 0[/COLOR]
okHost okHI(
.okUH(okUH),
.okHU(okHU),
.okUHU(okUHU),
.okAA(okAA),
.okClk(),
.okHE(okHE),
.okEH(okEH)
);

okWireOR # (.N(OK_endpoints)) wireOR (okEH, okEHx); // 3

okWireIn wi00(.okHE(okHE), .ep_addr(8’h00), .ep_dataout(ep00wire));
okWireOut wo20(.okHE(okHE), .okEH([COLOR="#FF0000"]okEHx(165)-1:065][/COLOR]), .ep_addr(8’h20), .ep_datain(ep20wire)); [COLOR="#FF0000"]// (65-1) :0[/COLOR]
okWireOut wo22(.okHE(okHE), .okEH(okEHx(265)-1:165]), .ep_addr(8’h22), .ep_datain(ep22wire)); [COLOR="#FF0000"]// (130-1):65[/COLOR]
okTriggerIn ti40(.okHE(okHE), .ep_addr(8’h40), .ep_clk(sys_clk), .ep_trigger(ep40wire));
okTriggerOut to60(.okHE(okHE), .okEH(okEHx(365)-1:265]), .ep_addr(8’h60), .ep_clk(sys_clk), .ep_trigger(ep60trig)); [COLOR="#FF0000"] // (195:1) : 130[/COLOR]

– end

my main interest is why doesn’t my code above work, as it looks very similar to the default VHDL code provided by O.K., which also makes sense :
but im currently doing a verilog design

– begin

[COLOR="#FF0000"]signal okEHx : STD_LOGIC_VECTOR(65*3-1 downto 0);[/COLOR]

– Instantiate the okHost and connect endpoints
okHI : okHost port map (
okUH=>okUH,
okHU=>okHU,
okUHU=>okUHU,
okAA=>okAA,
okClk=>open,
okHE=>okHE,
okEH=>okEH
);

okWO : okWireOR generic map (N=>3) port map (okEH=>okEH, okEHx=>okEHx);

ep00 : okWireIn port map (okHE=>okHE, ep_addr=>x"00", ep_dataout=>ep00wire);
ep20 : okWireOut port map (okHE=>okHE, okEH=>[COLOR="#FF0000"]okEHx( 165-1 downto 065 )[/COLOR], ep_addr=>x"20", ep_datain=>ep20wire); [COLOR="#FF0000"] – ((65-1) downto 0); – makes sense[/COLOR]
ep22 : okWireOut port map (okHE=>okHE, okEH=>[COLOR="#FF0000"]okEHx( 265-1 downto 165 )[/COLOR], ep_addr=>x"22", ep_datain=>ep22wire); [COLOR="#FF0000"] – ((130-1) downto 65);[/COLOR]
ep40 : okTriggerIn port map (okHE=>okHE, ep_addr=>x"40", ep_clk=>sys_clk, ep_trigger=>ep40wire);
ep60 : okTriggerOut port map (okHE=>okHE, okEH=>okEHx( 365-1 downto 265 ), ep_addr=>x"60", ep_clk=>sys_clk, ep_trigger=>ep60trig);

– end

2

We create a wire OR bus. For 10 signals on N ports in a wire OR bus, we generate a 10*N signal bus.

In Verilog:
[010 +: 10] references signals 0…9
[110 +: 10] references signals 10…19

In VHDL:
(9 downto 0) references signals 9…0
(19 downto 10) references signals 19…10

3

[QUOTE=Opal Kelly Support;4092]We create a wire OR bus. For 10 signals on N ports in a wire OR bus, we generate a 10*N signal bus.

In Verilog:
[010 +: 10] references signals 0…9
[110 +: 10] references signals 10…19

In VHDL:
(9 downto 0) references signals 9…0
(19 downto 10) references signals 19…10[/QUOTE]

Not exactly very insightful… i understand what is being defined… just not familliar with the [X +: Y] construct

In the examples you provide use the [X +: Y] construct in verilog [0:Z] , yet define the wire as reversed “wire [65*3-1:0] okEHx;” [Z] is there some reason for this?

and was more interested as to why is the endianess is different in verilog vs vhdl?
Is the OKhost primitive (ngc) designed as wire [0:195] vs [195:0]
Technically it shouldn’t matter i suppose, so why doesnt the following work?

wire (653)-1:0] okEHx; // (365)-1 : 0 => (195 -1) : 0] = [194:0]
okHost okHI(
.okUH(okUH),
.okHU(okHU),
.okUHU(okUHU),
.okAA(okAA),
.okClk(),
.okHE(okHE),
.okEH(okEH)
);

okWireOR # (.N(3)) wireOR (okEH, okEHx); // 3

okWireIn wi00(.okHE(okHE), .ep_addr(8’h00), .ep_dataout(ep00wire));
okWireOut wo20(.okHE(okHE), .okEH(okEHx(165)-1:065]), .ep_addr(8’h20), .ep_datain(ep20wire)); // (65-1) :0] = [64:0]
okWireOut wo22(.okHE(okHE), .okEH(okEHx(265)-1:165]), .ep_addr(8’h22), .ep_datain(ep22wire)); // (130-1):65] = [129:65]
okTriggerIn ti40(.okHE(okHE), .ep_addr(8’h40), .ep_clk(sys_clk), .ep_trigger(ep40wire));
okTriggerOut to60(.okHE(okHE), .okEH(okEHx(365)-1:265]), .ep_addr(8’h60), .ep_clk(sys_clk), .ep_trigger(ep60trig)); // (195-1) : 130] = [194:130]

I believe the problem is the way the okWireOR is defined in OkLibrary.v

module okWireOR # (parameter N = 1) (
output reg [64:0] okEH,
input wire [N*65-1:0] okEHx
);

integer i;
always @(okEHx)
begin
	okEH = 0;
	for (i=0; i  instead -
                   // but not sure if there if there are any other places this reversal is expected/needed [/B]

	end
end

endmodule

4

I think there is an issue of endian-ness.

Since [a +: b] is synonymous with [a : (a+b-1)], I think if you reverse your bits to:

.okEH(okEHx[065: (165)-1) instead of .okEH(okEHx[(165)-1:065]), it might work. I’m not sure about VHDL, but in Verilog if you switch the indices like that, it accesses the array of bits in reverse order.

I’m assuming the flipping of that bus, is flipping the wireOr bus, which then has the wrong bits assigned to the wrong function in the way OK uses the wireOr bus.