Author Topic: usb verilog softcore questions  (Read 2721 times)

0 Members and 1 Guest are viewing this topic.

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 878
  • Country: us
usb verilog softcore questions
« on: August 07, 2020, 02:17:12 am »
1. For this usb implementation : https://github.com/avakar/usbcorev/ , could anyone explain why the two variables below actually transmit some "state machine status"-related data ??

Code: [Select]
    assign tx_j = j;
    assign tx_se0 = se0;

2. May I know if https://github.com/osresearch/up5k/tree/master/usb is just a USB controller code OR USB-to-UART code ? Besides, I do not see any formal or simulation testbench.

 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11727
  • Country: us
    • Personal site
Re: usb verilog softcore questions
« Reply #1 on: August 07, 2020, 02:31:31 am »
1. They are outputs from this module indicating when top level needs to set J or SE0 state on the bus. I'm not sure what do you mean by "why". That's part of the USB logic. In some states you need to set specific values on the bus.
2. usb_uart is a top module. It has raw USB DP/DM pins on one end and UART RX/TX data on the other end.
Alex
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 878
  • Country: us
Re: usb verilog softcore questions
« Reply #2 on: August 07, 2020, 08:41:32 am »
When I try to write a testbench for the up5k usb_uart coding, Why do I have so many declaration errors ??

Quote
[phung@archlinux usb]$ iverilog -o usb_tb *.v
./../util.v:26: error: function declarations must be contained within a module.
usb_fs_in_arb.v:35: Module usb_fs_in_arb was already declared here: ./usb_fs_in_arb.v:1

usb_fs_in_pe.v:403: Module usb_fs_in_pe was already declared here: ./usb_fs_in_pe.v:2

usb_fs_out_arb.v:25: Module usb_fs_out_arb was already declared here: ./usb_fs_out_arb.v:1

usb_fs_out_pe.v:411: Module usb_fs_out_pe was already declared here: ./usb_fs_out_pe.v:2

./usb_fs_in_arb.v:35: Module usb_fs_in_arb was already declared here: ./usb_fs_in_arb.v:1

./usb_fs_in_pe.v:403: Module usb_fs_in_pe was already declared here: ./usb_fs_in_pe.v:2

./usb_fs_out_arb.v:25: Module usb_fs_out_arb was already declared here: ./usb_fs_out_arb.v:1

./usb_fs_out_pe.v:411: Module usb_fs_out_pe was already declared here: ./usb_fs_out_pe.v:2

./usb_fs_tx.v:267: Module usb_fs_tx was already declared here: ./usb_fs_tx.v:3

./usb_fs_tx_mux.v:16: Module usb_fs_tx_mux was already declared here: ./usb_fs_tx_mux.v:1

./usb_fs_rx.v:392: Module usb_fs_rx was already declared here: ./usb_fs_rx.v:3

usb_fs_pe.v:244: Module usb_fs_pe was already declared here: ./usb_fs_pe.v:9

usb_fs_rx.v:392: Module usb_fs_rx was already declared here: ./usb_fs_rx.v:3

usb_fs_tx_mux.v:16: Module usb_fs_tx_mux was already declared here: ./usb_fs_tx_mux.v:1

usb_fs_tx.v:267: Module usb_fs_tx was already declared here: ./usb_fs_tx.v:3

usb_serial_ctrl_ep.v:468: Module usb_serial_ctrl_ep was already declared here: ./usb_serial_ctrl_ep.v:3

usb_serial_ep.v:118: Module usb_serial_ep was already declared here: ./usb_serial_ep.v:1

./usb_fs_in_arb.v:35: Module usb_fs_in_arb was already declared here: ./usb_fs_in_arb.v:1

./usb_fs_in_pe.v:403: Module usb_fs_in_pe was already declared here: ./usb_fs_in_pe.v:2

./usb_fs_out_arb.v:25: Module usb_fs_out_arb was already declared here: ./usb_fs_out_arb.v:1

./usb_fs_out_pe.v:411: Module usb_fs_out_pe was already declared here: ./usb_fs_out_pe.v:2

./usb_fs_tx.v:267: Module usb_fs_tx was already declared here: ./usb_fs_tx.v:3

./usb_fs_tx_mux.v:16: Module usb_fs_tx_mux was already declared here: ./usb_fs_tx_mux.v:1

./usb_fs_rx.v:392: Module usb_fs_rx was already declared here: ./usb_fs_rx.v:3

./usb_fs_pe.v:244: Module usb_fs_pe was already declared here: ./usb_fs_pe.v:9

./usb_serial_ctrl_ep.v:468: Module usb_serial_ctrl_ep was already declared here: ./usb_serial_ctrl_ep.v:3

./usb_serial_ep.v:118: Module usb_serial_ep was already declared here: ./usb_serial_ep.v:1

usb_serial.v:233: Module usb_serial was already declared here: ./usb_serial.v:5

usb_tb.v:33: syntax error
usb_tb.v:17: error: Invalid module instantiation
usb_tb.v:35: error: invalid module item.
usb_tb.v:36: syntax error
usb_tb.v:40: error: invalid module item.
usb_tb.v:41: syntax error
usb_tb.v:41: error: Invalid module instantiation
usb_tb.v:42: error: Invalid module instantiation
usb_tb.v:43: error: Invalid module instantiation
usb_tb.v:44: error: Invalid module instantiation
usb_tb.v:46: error: invalid module item.
usb_tb.v:47: syntax error
usb_tb.v:47: error: Invalid module instantiation
usb_tb.v:49: error: invalid module item.
usb_tb.v:50: syntax error
usb_tb.v:50: error: Invalid module instantiation
usb_tb.v:52: error: invalid module item.
usb_tb.v:53: syntax error
usb_tb.v:53: error: Invalid module instantiation
usb_tb.v:55: error: invalid module item.
usb_tb.v:56: syntax error
usb_tb.v:58: error: invalid module item.
./usb_fs_in_arb.v:35: Module usb_fs_in_arb was already declared here: ./usb_fs_in_arb.v:1

./usb_fs_in_pe.v:403: Module usb_fs_in_pe was already declared here: ./usb_fs_in_pe.v:2

./usb_fs_out_arb.v:25: Module usb_fs_out_arb was already declared here: ./usb_fs_out_arb.v:1

./usb_fs_out_pe.v:411: Module usb_fs_out_pe was already declared here: ./usb_fs_out_pe.v:2

./usb_fs_tx.v:267: Module usb_fs_tx was already declared here: ./usb_fs_tx.v:3

./usb_fs_tx_mux.v:16: Module usb_fs_tx_mux was already declared here: ./usb_fs_tx_mux.v:1

./usb_fs_rx.v:392: Module usb_fs_rx was already declared here: ./usb_fs_rx.v:3

./usb_fs_pe.v:244: Module usb_fs_pe was already declared here: ./usb_fs_pe.v:9

./usb_serial_ctrl_ep.v:468: Module usb_serial_ctrl_ep was already declared here: ./usb_serial_ctrl_ep.v:3

./usb_serial_ep.v:118: Module usb_serial_ep was already declared here: ./usb_serial_ep.v:1

./usb_serial.v:233: Module usb_serial was already declared here: ./usb_serial.v:5

[phung@archlinux usb]$




usb_tb.v

Code: [Select]
module usb_tb();

reg clk, clk_48mhz;
reg reset;

wire pin_usbp, pin_usbn;
wire pin_pu;

wire [7:0] rx_data;
wire rx_strobe;
reg [7:0] tx_data;
reg tx_strobe;

assign pin_usbp = tx_strobe ?  tx_data : 1'bz;
assign pin_usbn = tx_strobe ? !tx_data : 1'bz;

usb_uart dut
(
.clk(clk),
.clk_48mhz(clk_48mhz),
.reset(reset),

.pin_usbp(pin_usbp),
.pin_usbn(pin_usbn),
.pin_pu(pin_pu),

.rx_data(rx_data),
.rx_strobe(rx_strobe),
.tx_data(tx_data),
.tx_strobe(tx_strobe)
)

initial begin
  $dumpfile("usb_tb.vcd");
  $dumpvars(1);
end

initial
begin
clk = 0;
clk_48mhz = 0;
reset = 0;
tx_data = 0;
tx_strobe = 1;

@(posedge clk);
tx_data = 1;

@(posedge clk);
tx_data = 2;

@(posedge clk);
tx_data = 3;

#50 $finish;
end

always #5  clk =  ! clk;
always #10  clk_48mhz =  ! clk_48mhz;

endmodule
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11727
  • Country: us
    • Personal site
Re: usb verilog softcore questions
« Reply #3 on: August 07, 2020, 04:44:39 pm »
The multiple declarations is because they are using includes all over the place, so you only need to specify one top file to the iverilog, it will pick up the rest of the files though includes.

In your TB this part:
Code: [Select]
assign pin_usbp = tx_strobe ?  tx_data : 1'bz;
assign pin_usbn = tx_strobe ? !tx_data : 1'bz;
is nonsense. tx_strobe is the UART signals and tx_data is 8-bit parallel signal.

pin_usbp and pin_usbn are already direct connections to the USB pins.

You also don't have semicolon after the module instantiation.
Alex
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 878
  • Country: us
Re: usb verilog softcore questions
« Reply #4 on: August 07, 2020, 05:26:18 pm »

Quote
[phung@archlinux usb]$ git grep "../util.v"
serial-demo.v://`include "../util.v"
usb_uart.v:`include "../util.v"
[phung@archlinux usb]$ iverilog -o usb_tb usb_uart.v
./../util.v:26: error: function declarations must be contained within a module.

[phung@archlinux usb]$ git grep "../util.v"
serial-demo.v://`include "../util.v"
usb_uart.v://`include "../util.v"
[phung@archlinux usb]$ iverilog -o usb_tb usb_uart.v
usb_uart.v:42: error: Unknown module type: fifo
usb_uart.v:93: error: Unknown module type: SB_IO
3 error(s) during elaboration.
*** These modules were missing:
        SB_IO referenced 1 times.
        fifo referenced 1 times.
***
[phung@archlinux usb]$

from the quoted output above, it seems that I still have the same error even with a single instance of "../util.v"

I have added a semicolon after the dut module instantiation.

How would you handle an "inout" signal inside verilog testbench since both "pin_usbp" and "pin_usbn" are "inout" signals ?
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11727
  • Country: us
    • Personal site
Re: usb verilog softcore questions
« Reply #5 on: August 07, 2020, 05:46:51 pm »
The errors in util.v may be related to limitations of iverilog. You may need to rewrite relevant code in a compatible way. You may need to just move this function inside every module that uses it.

Bidirectional signals are not easy to work with. It is much easier to look at what signal controls the direction of the pin inside the hierarchy and use that.

But also, are you really going to simulate the whole behaviour of the host controller? This is not trivial at all.
Alex
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 878
  • Country: us
Re: usb verilog softcore questions
« Reply #6 on: August 08, 2020, 03:17:19 am »
Quote
[phung@archlinux usb]$ iverilog -o usb_tb usb_uart.v usb_tb.v
usb_tb.v:27: warning: output port rx_data is coerced to inout.
usb_tb.v:28: warning: output port rx_strobe is coerced to inout.
[phung@archlinux usb]$ vvp usb_tb
VCD info: dumpfile usb_tb.vcd opened for output.

^C** VVP Stop(0) **
** Flushing output streams.
** Current simulation time is 0 ticks.
> finish
** Continue **
[phung@archlinux usb]$ git status --short
 M usb_serial_ep.v
 M usb_uart.v
 M ../util.v
?? build.sh
?? usb_tb
?? usb_tb.v
?? usb_tb.vcd
[phung@archlinux usb]$ git diff usb_serial_ep.v
diff --git a/usb/usb_serial_ep.v b/usb/usb_serial_ep.v
index e90d817..b813028 100644
--- a/usb/usb_serial_ep.v
+++ b/usb/usb_serial_ep.v
@@ -23,7 +23,7 @@ module usb_serial_ep (
   input in_ep_grant,
   input in_ep_data_free,
   output reg in_ep_data_put = 0,
-  output [7:0] in_ep_data,
+  output reg [7:0] in_ep_data,^M
   output reg in_ep_data_done = 0,
   output in_ep_stall,
   input in_ep_acked,
@@ -37,7 +37,7 @@ module usb_serial_ep (
   input uart_tx_strobe,
 
   output [7:0] uart_rx_data,
-  output uart_rx_strobe
+  output reg uart_rx_strobe^M
 );
   // never stall the USB
   // todo: allow backpressure to stall the serial link
[phung@archlinux usb]$ git diff usb_uart.v
diff --git a/usb/usb_uart.v b/usb/usb_uart.v
index 2ec7c31..d641a94 100644
--- a/usb/usb_uart.v
+++ b/usb/usb_uart.v
@@ -3,6 +3,7 @@
 
 `include "usb_serial.v"
 `include "../util.v"
+`include "/usr/share/yosys/ice40/cells_sim.v"^M
 
 module usb_uart (
   input  clk,
[phung@archlinux usb]$ git diff ../util.v
diff --git a/util.v b/util.v
index 6c55b8d..910cab2 100644
--- a/util.v
+++ b/util.v
@@ -22,7 +22,7 @@
    x <= 32768   ? 15 : \
    x <= 65536   ? 16 : \
    -1
-
+/*
 function [7:0] hexdigit;
        input [3:0] x;
        begin
@@ -46,7 +46,7 @@ function [7:0] hexdigit;
                        "?";
        end
 endfunction
-
+*/
 module divide_by_n(
        input clk,
        input reset,
@@ -112,7 +112,7 @@ endmodule
 module pwm(
        input clk,
        input [BITS-1:0] bright,
-       output out
+       output reg out
 );
        parameter BITS = 8;
 
[phung@archlinux usb]$

I do not understand why "vvp" stops forever at simulation time tick of 0th clock tick ??

usb_tb.v : simulation testbench

Code: [Select]
module usb_tb();

reg clk, clk_48mhz;
reg reset;

wire pin_usbp, pin_usbn;
wire pin_pu;

wire [7:0] rx_data;
wire rx_strobe;
reg [7:0] tx_data;
reg tx_strobe;

assign pin_usbp = tx_strobe ?  tx_data : 1'bz;
assign pin_usbn = tx_strobe ? !tx_data : 1'bz;

usb_uart dut
(
.clk(clk),
.clk_48mhz(clk_48mhz),
.reset(reset),

.pin_usbp(pin_usbp),
.pin_usbn(pin_usbn),
.pin_pu(pin_pu),

.rx_data(rx_data),
.rx_strobe(rx_strobe),
.tx_data(tx_data),
.tx_strobe(tx_strobe)
);

initial begin
  $dumpfile("usb_tb.vcd");
  $dumpvars(1);
end

initial
begin
clk = 0;
clk_48mhz = 0;
reset = 0;
tx_data = 0;
tx_strobe = 1;

@(posedge clk);
tx_data = 1;

@(posedge clk);
tx_data = 2;

@(posedge clk);
tx_data = 3;

#50 $finish;
end

always #5  clk = !clk;
always #10  clk_48mhz = !clk_48mhz;

endmodule
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11727
  • Country: us
    • Personal site
Re: usb verilog softcore questions
« Reply #7 on: August 08, 2020, 03:23:00 am »
Your TB still makes no sense.

But also may need something like "`timescale 1ns / 1ps" at the beginning of a file.
Alex
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 878
  • Country: us
Re: usb verilog softcore questions
« Reply #8 on: August 08, 2020, 07:57:42 am »
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11727
  • Country: us
    • Personal site
Re: usb verilog softcore questions
« Reply #9 on: August 08, 2020, 08:02:57 am »
Your TB still makes no sense. Why are you insisting on this stuff:
Code: [Select]
assign pin_usbp = pin_pu ?  tx_strobe :  rx_strobe;
assign pin_usbn = pin_pu ? ~tx_strobe : ~rx_strobe;

Why are you connecting serial side signals to the USB pins?
Alex
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 878
  • Country: us
Re: usb verilog softcore questions
« Reply #10 on: August 08, 2020, 09:52:24 am »
How should I handle the testbench stimulus for these 2 usb signals ?

Generate real-time usb signals using libusb software library ?

Code: [Select]
  inout  pin_usbp,
  inout  pin_usbn,
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11727
  • Country: us
    • Personal site
Re: usb verilog softcore questions
« Reply #11 on: August 08, 2020, 06:08:12 pm »
Yes, you need to implement a hot part of the USB specification. It is not trivial at all, even if just for simulation. It is really not worth it.

For your test right now try to not connect them at all.  There may be some loops because of the way you are doing it, and vvp may get confused.
Alex
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 878
  • Country: us
Re: usb verilog softcore questions
« Reply #12 on: August 09, 2020, 01:40:14 am »
Quote
For your test right now try to not connect them at all.  There may be some loops because of the way you are doing it, and vvp may get confused.

What can I do to get past "vvp" if I do not generate USB traffic stimulus for the simulation testbench ?
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11727
  • Country: us
    • Personal site
Re: usb verilog softcore questions
« Reply #13 on: August 09, 2020, 01:42:02 am »
Assume that the USB core works correctly and only simulate your part working with the serial interface. Basically make a dummy IP with just the serial interface and control that from the TB avoiding the whole USB simulation.

What do you want from that simulation? If you want to see how the core works internally, then there is no way to avoid simulating the host.
Alex
 
The following users thanked this post: Bassman59

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 878
  • Country: us
Re: usb verilog softcore questions
« Reply #14 on: August 09, 2020, 08:34:33 am »
Quote
Basically make a dummy IP with just the serial interface and control that from the TB avoiding the whole USB simulation.

What do you exactly mean by "dummy IP with just the serial interface" ?
I suppose I still need to handle "pin_usbp" and "pin_usbn" ?

One other issue is a failed timing analysis with the original code
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11727
  • Country: us
    • Personal site
Re: usb verilog softcore questions
« Reply #15 on: August 09, 2020, 08:41:11 am »
Again, what is your goal with this simulation? If you want to debug the core itself, then the only option is to create a corresponding host model (at least behavioral).

Otherwise, if you just want to test your own logic that uses this USB IP, just create a block that only has rx_data,  rx_strobe,  tx_data and tx_strobe. This is enough to test integration of the USB IP with your system.

Open source tools for ice40 known to suck at timing. They don't really have a way to input any timing constraints and optimize the design for that. So your only hope is to run it with different seeds and hope that one of the random placements ends up being good enough.
Alex
 

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 878
  • Country: us
Re: usb verilog softcore questions
« Reply #16 on: August 10, 2020, 08:03:16 am »
How exactly is this testbench used in a loopback manner ?
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11727
  • Country: us
    • Personal site
Re: usb verilog softcore questions
« Reply #17 on: August 10, 2020, 08:09:20 am »
This is not a test bench. It is still a code that describes a loopback on the serial side. So any characters you type into the COM-port will be sent back to the same port.

This still needs USB connection and run on a real hardware.
Alex
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 878
  • Country: us
Re: usb verilog softcore questions
« Reply #18 on: August 12, 2020, 07:25:31 am »
Who have a real-time captured USB2.0 (D+ and D-) waveform in vcd format ?
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11727
  • Country: us
    • Personal site
Re: usb verilog softcore questions
« Reply #19 on: August 12, 2020, 07:36:49 am »
What do you want to do with is? A simple capture will not help a lot for a test bench. USB protocol is reasonably complicated that you need to actively react to the bust state, not just playback pre-recorded signals.

This site has a reasonably good explanation of the signalling on the bus and token and packet formats http://www.usbmadesimple.co.uk/ums_3.htm  (all parts are a good read, not just this one).

I'm not aware of any pre-recorded log files that would show full transactions.
Alex
 
The following users thanked this post: promach

Offline promachTopic starter

  • Frequent Contributor
  • **
  • Posts: 878
  • Country: us
Re: usb verilog softcore questions
« Reply #20 on: August 13, 2020, 08:51:44 am »
Quote
I'm not aware of any pre-recorded log files that would show full transactions.

I can use these sigrok-compatible log signals files

However, analyzing the following decoded USB signals would really take some time.

 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11727
  • Country: us
    • Personal site
Re: usb verilog softcore questions
« Reply #21 on: August 13, 2020, 04:40:51 pm »
Well, yes, as I said making a test bench for the USB host is not a trivial task. It is probably comparable in complexity to making the USB device core itself.

The only thing that makes it simpler is that TB does not need to be synthesizeable. But in reality it is not much.
Alex
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf