Cora Z7-0S AXI for external DAC

[satvik]

Thank you, supporters in advance.

I am working on Custom Axi slave IP core on  ZYNQ based digilent Cora-Z0S board in vivado 2018.2.

I successfully have done its example and add my own logic which is working fine with ARM and I can receive data in ARM(C code).

After that, I  connect my IP core to the external port like led(onboard) and some physical pins for my external DAC module. I added the ports into custom IP Verilog code according to my design and it appears in GUI as well. Then I connect that custom IP to ZYNQ in block design and make those led and other ports as extern by right click on it and assign the pin number using pin layout. I got successfully generated the bit-stream.

The problem starts when I upload the bit-stream on board then I am not getting any output on any pin. the led consciously blow if I assign 1'b1 to it in initialize block. I made all output including led as register.  Then I include onboard button and using assign statement assign button value to led(change reg to wire) then only it works but it is not working when I use led(change back to reg) and button in always block and apply button value to led (led <= button;).

I generate test-bench and in that, I am getting all value on all ports the same as my desire but not from board physical pins. 

I attached the custom AXI IP core vivado project(DacTestIP.rar).

Please help me. I am wondering what mistake am I making?

DacTestIP.rar

[D@n]

@satvik,

Nevermind--I figured out how to open your archive.  Here are some of the things I discovered while looking at the file testDAC3_v1_0_S00_AXI.v:

1. You are using Xilinx's IP packager's code to start out.  You should be aware that this logic is broken, and will likely cause your design to lock up eventually.  It makes one of the more common AXI mistakes within it.  The design has now been broken for about 4 yrs, and its a shame Xilinx has yet to publish an errata to Vivado for it.  You can find an alternative implementation here.  I'd recommend formally verifying your AXI-lite IP before trying to place it onto hardware.  It's fast, and fairly painless, but will also find these bugs for you.
2. I recommend to all that they start any design file with "`default_nettype none" and then, before running Vivado to try to synthesize the design, that they run "verilator -Wall -cc file.v".  You'll find a lot of bugs this way, and you'll find them much faster than it takes Vivado to even start considering your files.  If you can get Verilator to pass your design without warnings, chances are your bug will be fixed.  (In this case, and having looked at your code, I'm pretty well convinced this would be so.)
3. You have declared cnt as a value with 33 bits in it, but are then only operating on 32 of them.   This appears to be an error, although not yet the error you are struggling with.  You'll also find it's easier to compare against 32'd_100_000_000 than the binary value you have.  Even 32'h05f5e100 would be easier to follow.
4. led0 isn't used.  This plus cnt are probably removed from your design by the optimizer.
5. Your commented assign, "assign led=Led;" would fail with the symptoms you've described above, simply because Led is never assign in your IP.  Verilator would've caught this for you.

Hope that helps,

Dan

[D@n]

@satvik,

I'd like to help, but my system doesn't seem to know how to open your archive file.

Can you just attach your AXI slave IP by itself?  The Verilog (or VHDL) file?

Thanks!

Dan

[zygot]

@D@n, as usual provides some valuable insight that most people would have missed.

My first comment has to do with using the AVI-Lite bus. I agree with Dan that AXI busses, even the 'lite' ones are overly complicated for most PS-PL designs. If you are going to use a standard bus then you have to understand how it works.. before designing with it. Bussing signals doesn't have to be complicated. If you want to have IP ownership over a technology then you embed lots of functionality into your bus standard and it becomes complicated. In general I avoid Wishbone, AXI and other similar bus standards to the extent possible. It's horrifying that an FPGA vendor would promote and propagate bad design habits to their customers.

One way to side-step using a bus with complications that you don't want to deal with or complexity that you don't need is to not expose the bus to IO pins in your board design schematic. The dual-port BRAM controller is one interface that I've used; exposing the signals on side to external pins in the board design. Once I've generated the board design I always have Vivado generate and HDL wrapper, that I, not Vivado, controls and use that wrapper as an instantiated design element in my own toplevel design file. I can then instantiate any number of additional components into my toplevel design as if it were an all HDL project. I have to take care of more details this way but I've found this to be a lot more manageable and a lot less frustrating way to do ZYNQ designs.

My second comment has to do with Dan's discussion about the flaws in Vivado generated code. I'm all in favor of using a tool to identify bad code, when it's available. Everyone, regardless of experience, writes poor code at some point or another; if you have access to a "brain-fart" checker then why not use it? As long as it doesn't automatically change your source, the way that a spell checker does I don't see a downside. In the case of the if-the-else structure you have to make sure that all possible conditions and all possible states for those conditions are handled. This is not always easy to do. Even evaluating the output of such logic isn't always straight forward. Nested if-then-else structures can have multiple combinatorial logic levels and unpredictable delays and behavior. Understand the implications that come with using a particular coding structure when doing synthesis for logic design.

There are two types of resets, synchronous and asynchronous. You can have both types in your process statements. Be aware that the concept of logic reset isn't nearly as simple as one would assume. 

[satvik]

7 hours ago, D@n said:

@satvik,

Nevermind--I figured out how to open your archive.  Here are some of the things I discovered while looking at the file testDAC3_v1_0_S00_AXI.v:

1. You are using Xilinx's IP packager's code to start out.  You should be aware that this logic is broken, and will likely cause your design to lock up eventually.  It makes one of the more common AXI mistakes within it.  The design has now been broken for about 4 yrs, and its a shame Xilinx has yet to publish an errata to Vivado for it.  You can find an alternative implementation here.  I'd recommend formally verifying your AXI-lite IP before trying to place it onto hardware.  It's fast, and fairly painless, but will also find these bugs for you.
2. I recommend to all that they start any design file with "`default_nettype none" and then, before running Vivado to try to synthesize the design, that they run "verilator -Wall -cc file.v".  You'll find a lot of bugs this way, and you'll find them much faster than it takes Vivado to even start considering your files.  If you can get Verilator to pass your design without warnings, chances are your bug will be fixed.  (In this case, and having looked at your code, I'm pretty well convinced this would be so.)
3. You have declared cnt as a value with 33 bits in it, but are then only operating on 32 of them.   This appears to be an error, although not yet the error you are struggling with.  You'll also find it's easier to compare against 32'd_100_000_000 than the binary value you have.  Even 32'h05f5e100 would be easier to follow.
4. led0 isn't used.  This plus cntare probably removed from your design by the optimizer.
5. Your commented assign, "assign led=Led;" would fail with the symptoms you've described above, simply because Led is never assign in your IP.  Verilator would've caught this for you.

Hope that helps,

Dan

Hellow @D@n,

 

Thank you for valuable reply and i am following your all previous comments. I accept all your suggestion and i want to say that i put my led login in file TestDAC3_v1_0.V if you can check it. I apologize to attache my old version IP core project buti will follow your suggestion and try with axi-lite. 

My aim is to get data from ARM processor to FPGA and then pass it to PmodeDAC using my spi logic. Now I successfully test ramp up signal on PmodeDAC and pack that verilog code in IP core. Once again i creat new block design and put only my PmodeDAC IP core(no AXI only pure SPI core of mine) connect external clock and pmode pins and it work fine on my board.

But i need to connect it with zynq soc ip so i added zynq soc ip and connect my ip core's clk pin to zynq FCLK_0(set 100Mhz) pin and genratebit stream successfully.

When i load my board theni got nothing on that PmodeDAC. 

Is ther any working code with tutorial which send data from ARM to FPGA IP core and process in fPGA and send to physical pin even on board led or something similar.

I really really need help in this.

I will upload my pmodeDAC.

 

Once again thank you so much   

[D@n]

@satvik,

I'm not seeing any bugs in TestDAC3_v1_0.v.  If there are any there, they aren't standing out to me.

Dan

[satvik]

@D@n,

Thank you @D@n and @zygot

If there is no bug and error then why my led is continuously stay ON, its like no effect of button press. If I put only "assign led = button;" instead of always block it works fine. What is the reason behind that?

[zygot]

All of my designs have a 32 or 48 bit free running counter for multiple uses. One is a sanity check to make sure that the clock is there.  For a 100 MHz clock bit 24 toggles an LED at a nice rate.

[satvik]

Hello @D@n and @zygot

Sorry for late reply and thank you somuch for your support as always you did.

Finally i got the actual problem in my case is, i connected my IP core to Zynq SOC clock out (FCLK_CLK0) but i was uploading the bit file from vivado Hardware Manager and expect to get output without running any application form SDK. 

When i run application from SDK then only the  FCLK_CLK0 give clock out.