Simulating UDB / datapath

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

Hello,

I'm digging deeper into simulating UDBs and datapaths, using iVerilog and GtkWave. I managed to get this to work on a basic level with very simple test benches. This is ideal for me because it allows for faster component development since it's not needed to re-compile and re-flash the device after each change of the component. I wonder if other users are also simulating UDB / datapath and have some general tipps for writing the test benches.

While visualizing the waveforms with GtkWave, I recognized that some signals (internal as well as the outputs) of the UDB / datapath are in an unknown state, e.g. 'x'. Even the signals where I expected an output are in this state. I wonder if it's neccessary to setup the component in a special way within the test bench which would otherwise be done by the PSoC device.

Currently I'm especially interested in how to setup the test bench for simulating CPU access of the datapath registers and FIFOs - I'm using the FIFO in single-byte mode (holding it in reset state via the AUX register), but when I try to access the FIFO with the task 'fifo0_read' the simulation hangs.

Regards

0 Likes
1 Solution
RodolfoGL
Employee
Employee
250 solutions authored 250 sign-ins 5 comments on KBA

Hello,

I was able to setup my environment and run the simulation.

Since in 1-byte mode you treat it as a register, you can directly read the register using "dut.UDB2FIFO_DP.fifo0_data_out".

To write though, you can create a new Verilog function that does not rely on the bus stat:

 

task fifo0_reg_write;
   input [07:00] data;
begin
   cpu_fifo_wr0 = 1'b1;
   cpu_data = data;
   @(posedge cpu_clock);
   cpu_fifo_wr0 = 1'b0;
end
endtask

 

But not that you need to setup the FIFO INSEL to be BUS to make the FIFO write useful.

View solution in original post

0 Likes
15 Replies
lock attach
Attachments are accessible only for community members.
RodolfoGL
Employee
Employee
250 solutions authored 250 sign-ins 5 comments on KBA

Hello,

I totally agree with you. Simulating UDBs and datapaths really accelerates the development flow. I have used a few times when I get to implement some complex logic.

I have an example to share. I implemented a zero cross-rating algorithm in hardware using Verilog, which relies on FIFO accesses. I had to simulate DMA writes and reads to the FIFO.

Hope this helps a bit.

 

 

0 Likes

Hello @RodolfoGL 

thank you for this project, I'll go through it. As far as I can see you're not doing any special datapath configuration in the testbench. You're using the FIFO in 4-byte mode. In my case, I'm using the FIFO as 1-byte register (FIFO RST flag kept at logic one), done as one of the first instructions in the testbench.

Do you think this is the issue why my testbench hangs when using FIFO_READ task? I'm not sure if this task shall be used in 1-byte mode to read the FIFO since it checks some status signals. Initially I thought that it's needed to configure internal signals of the datapath within the testbench (which is done by MCU in the real device), but in your testbench code there's no special configuration, so I assume it usually runs out of the box...

Regards

0 Likes
RodolfoGL
Employee
Employee
250 solutions authored 250 sign-ins 5 comments on KBA

In this case, you need to write to the aux_ctrl signal from the datapath module. To use in 1-byte mode, you need to set bit 0 (for FIFO 0) and bit 1 (for FIFO 1).

0 Likes

Hello @RodolfoGL 

Yes, as I wrote above I did this in my testbench and then used FIFO_READ, but the simulation hangs. Without using FIFO_READ it finish.

Regards

0 Likes

Are you clocking the datapath? There is a cpu_clock signal that needs to be assigned.

If you did and it is still not working, can you share your testbench file?

0 Likes

Hello @RodolfoGL 

yes, the datapath is also clocked. I'll provide an example file later this day.

Regards

0 Likes
lock attach
Attachments are accessible only for community members.

Hello @RodolfoGL 

Attached you'll find a demo setup. The simulation is done with Icarus iVerilog and the waveforms are shown with GtkWave.
The component simply increments A0 and the value is shown on parallel output.

The current testbench has the FIFO read access from CPU commented out, otherwise the simulation won't proceed. Also included in the attachment is a screenshot of the current TB waveform:

GTKWave - UDB2FIFO_TB.png

Unfortunately, GtkWave (or the VCD file itself) doesn't show the signal hierarchy, e.g. 'fifo_wr_data' exists for both FIFO0 and FIFO1. The same applies for other signals.

I tried to show all relevant signals, so you can see there's a CPU clock, a component clock, etc. The AUX_CTRL register is set to 0x03, so the FIFOs should be in 1-byte mode. As you can see in the waveforms, a write to SOME PART of the FIFOs is occuring on each clock. Not shown are the Fx_LOAD signals, but it seems they found their way into the datapath. But the corresponding tasks for CPU access seem to check for Fx_BUS_STAT, which never change... So, I wonder if I'm doing something wrong in my testbench, or if using the R/W tasks in 1-byte mode is the wrong approach or if the provided Verilog code simply doesn't take 1-byte mode into account.

Regards

0 Likes
RodolfoGL
Employee
Employee
250 solutions authored 250 sign-ins 5 comments on KBA

I don't have my computer setup to do simulation, but I have a few notes:

1) Don't add this code. It will keep reading all the time.

//	always @clk
//	begin
//		dut.UDB2FIFO_DP.fifo0_read(FIFO0_dat);
//		dut.UDB2FIFO_DP.fifo1_read(FIFO1_dat);
//	end

2) If you use 1-byte mode, the Fx_BUS/BLK_STAT don't work.

Besides that, I don't see any thing wrong with your simulation wave signals and code. You should be able to read the FIFOs on your "initial" block. If you don't set the AUX_CTRL, does it still crash?

0 Likes

Hello @RodolfoGL 

1) Here the idea was to read the result of the datapath on each component clock (however, it should use posedge, it's an error to trigger on both edges).

2) Okay - that explains why the read/write tasks don't work. Then how to read/write FIFO in 1-byte mode?

I'll check if the setup works without setting 1-byte mode.

Regards

0 Likes
RodolfoGL
Employee
Employee
250 solutions authored 250 sign-ins 5 comments on KBA

Hello,

I was able to setup my environment and run the simulation.

Since in 1-byte mode you treat it as a register, you can directly read the register using "dut.UDB2FIFO_DP.fifo0_data_out".

To write though, you can create a new Verilog function that does not rely on the bus stat:

 

task fifo0_reg_write;
   input [07:00] data;
begin
   cpu_fifo_wr0 = 1'b1;
   cpu_data = data;
   @(posedge cpu_clock);
   cpu_fifo_wr0 = 1'b0;
end
endtask

 

But not that you need to setup the FIFO INSEL to be BUS to make the FIFO write useful.

0 Likes

Hello @RodolfoGL 

thank you, that looks good. I'll implement it as you suggested. So, in fact, for 1-byte access to the FIFOs it's duplicating both the read and the write task and removing the wait for bus stat signal. This will have the same result, right?

Any other general tipps for simulation of datapaths? Which tools are you using?

Regards

0 Likes

I tried to implement the READ task as well, but that didn't work for some reason. In any case, it is easier to simply access the register fifo0_data_out for reads.

I'm using Modelsim.

0 Likes

Hello @RodolfoGL 

oh, okay... I want to check that the FIFO register is updated at the same time when the component updates the parallel output. So, does reading fifo0_data_out without synchronizing to cpu_clock reflect the real behaviour?

Regards

0 Likes

You are not going to emulate the exact CPU code in your testbench, so I would say it is very close to the real behavior. Reading the FIFO in 1-byte mode does not affect anything in the hardware. 

0 Likes

Hello @RodolfoGL 

Okay, sounds good. I'll verify the behaviour as you suggested. Thank you for your help.

Regards

0 Likes