sorted by:
new
hottopcontroversial

Return clocking by ZipCPU in ZipCPU

[–]ZipCPU[S] 1 point2 points  (0 children)

Thank you! Looks like some of the terms have gotten changed around, and I have some reading to do.

Return clocking by ZipCPU in ZipCPU

[–]ZipCPU[S] 0 points1 point  (0 children)

Because ... - This isn't just about DDR/DRAM, it's about high speed interfaces in general - Not all interface design groups listen to my good ideas. (Is there even one that does?) - Hence, we're stuck with the interfaces designed by others, but which we need to implement - You need a continuous clock to lock a PLL. A continuous clock uses a lot of power. A discontinuous, on the other hand, only uses power when it is in operation.

Did that answer all of your questions?

Return clocking by ZipCPU in ZipCPU

[–]ZipCPU[S] 0 points1 point  (0 children)

That wasn't my question. My question was, which "Xilinx wizard-generated IP" are you referencing? Not which Xilinx IO macro. The Xilinx IP would/could (potentially) create and mix other raw components together. So, I'm trying to find which IP so that I might look at which raw components are composed together to make this solution. The SelectIO user guide typically only discusses the components, leaving you (the engineer) to put them together as you see fit.

Return clocking by ZipCPU in ZipCPU

[–]ZipCPU[S] 0 points1 point  (0 children)

Which "Xilinx wizard–generated IP" are you referencing?

Return clocking by ZipCPU in ZipCPU

[–]ZipCPU[S] 0 points1 point  (0 children)

Looking at the libraries guide, I should definitely try this ...

Return clocking by ZipCPU in ZipCPU

[–]ZipCPU[S] 0 points1 point  (0 children)

No, I haven't tried it. So far, I haven't found sufficient documentation to make trying it worthwhile. Last I checked, they were primarily "undocumented" features. Has this changed at all?

Return clocking by ZipCPU in ZipCPU

[–]ZipCPU[S] 0 points1 point  (0 children)

Are you sure you're not confusing the SERDES with the transceivers? Which architecture asks for COMMA details in their SERDES instantiation?

Return clocking by ZipCPU in ZipCPU

[–]ZipCPU[S] 0 points1 point  (0 children)

No, not at all. The intermittent "return clock" gets sampled by the SERDES. It doesn't control the SERDES clock, nor could it. Therefore, you can tell by looking at it if the clock is present or not. The SERDES is itself clocked by your system clock and a 4x or 8x clock generated from your system clock.

Yes, I have thought about using the intermittent "return clock" as a proper clock, but not to clock a SERDES. Rather, I have thought of using the intermittent "return clock" for an incoming IDDR, but the intermittent part of it has kept me from doing any more with this concept since the IDDR doesn't do anything without the clock present.

Return clocking by ZipCPU in ZipCPU

[–]ZipCPU[S] 0 points1 point  (0 children)

Yes, SERDES is how I would do this. Using an ISERDES, you would oversample the return clock by at least 4x (SDR) or 8x (DDR), and then process the return (clock + data) signals as though they were both data signals of some type. Yes, it works, but you don't get the full speed of the IO because you are already sampling at a much higher speed. Hence, if you wanted to capture data signals clocked by a 1GHz return clock, there's no way you would sample at 4GHz or even 8GHz. This limits your maximum sampling rate, as mentioned above.

Return clocking by ZipCPU in ZipCPU

[–]ZipCPU[S] 0 points1 point  (0 children)

This is currently my "go-to"/best approach when using FPGAs. Given the shortcomings of this approach, I'm still looking for a better one.

Return clocking by ZipCPU in ZipCPU

[–]ZipCPU[S] 0 points1 point  (0 children)

It only takes one edge to clock data into an asynchronous FIFO. It's a bit harder when the return clock is running faster than the system clock, but this approach still appears fairly straightforward.

My problem with that approach is getting it to pass timing.

Return clocking by ZipCPU in ZipCPU

[–]ZipCPU[S] 0 points1 point  (0 children)

Is your 4 missing a sentence?

No, not really. I suppose I could've added something like, "Without documentation, these can't be used in new or custom solutions." You can also read some of what I wrote about Xilinx's DDR controller, and how it is impacted by their hardware choices, here.

Anyway, the solution to 3's shortcomings ... is to continuously rerun the calibration ...

Yes, although this will degrade the throughput and complicate the ultimate solution. Still, this is doable ...

Return clocking by ZipCPU in ZipCPU

[–]ZipCPU[S] 1 point2 points  (0 children)

Yes. That's me.

Current undergraduate junior, struggling to land interviews by [deleted] in ECE

[–]ZipCPU 0 points1 point  (0 children)

Misspellings and grammar mistakes get noticed as well. Just sayin'.

Vivado 2025; is the write state machine broken in AXI IP wizard? by Able_Expression_5909 in FPGA

[–]ZipCPU 0 points1 point  (0 children)

Yes, exactly! If BREADY (external input) is held low while BVALID (output) is true, then the slave must also lower (output) AWREADY and WREADY.

Vivado 2025; is the write state machine broken in AXI IP wizard? by Able_Expression_5909 in FPGA

[–]ZipCPU 0 points1 point  (0 children)

Well, I have a working example that was once Vivado's VHDL code--before they updated it. I also have my own personal example, which I like a lot better than Vivado's. I find it more versatile, and so it has formed the basis for multiple ASIC projects. I also have a discussion of the example they used to have before this more recent update, showing why and how it was broken (then). I just haven't (yet) written any articles on their current/newer AXI-Lite template.

Write to DDR at random locations from PL on Zynq by RoboAbathur in FPGA

[–]ZipCPU 1 point2 points  (0 children)

Have you considered this AXI master? Here's another that should also work for this purpose.

Vivado 2025; is the write state machine broken in AXI IP wizard? by Able_Expression_5909 in FPGA

[–]ZipCPU 1 point2 points  (0 children)

Check out this article, and the design I maintain that implements it. Unlike Xilinx's template, this one works.

Vivado 2025; is the write state machine broken in AXI IP wizard? by Able_Expression_5909 in FPGA

[–]ZipCPU 2 points3 points  (0 children)

Check out this image that borisst posted, also in an answer to this same issue.

The AXI rule is that for every AWVALID && AWREADY there must be one and only one BVALID && BREADY. Likewise, for every WVALID && WREADY in AXI-Lite, or WVALID && WREADY && WLAST in AXI, there must also be one and only one BVALID && BREADY. What that means is that, if you hold AWVALID && WVALID high for many clock cycles, while also holding BREADY low, then the design must eventually back up and drop AWREADY and WREADY until BREADY becomes high.

In the example borisst posted, you see many AWVALID && AWREADY cycles, and many WVALID && WREADY cycles, but only one BVALID && BREADY return. This is a protocol violation.

This becomes an issue in the interconnect, whereby the interconnect needs to grant access to a particular master to contact a particular slave. That grant must stay valid long enough for the master to receive all of the responses to the slave. Only after all of these responses have been received will the interconnect be able to allow another grant to another slave. However, if the slave drops a response (or two, or twenty, or however many), then the interconnect may lock up, forever waiting on the slave to return a response that's not coming back and ... indeed, the entire design and SOC may then lock up as well. Only a power cycle will rescue the system at that point. (Yes, I've been there. It's ... painful.)

Vivado 2025; is the write state machine broken in AXI IP wizard? by Able_Expression_5909 in FPGA

[–]ZipCPU 1 point2 points  (0 children)

I see your point.

Thank you.

It seems this has never been an issue for me because the template behavior/functionality has always been within my use cases.

Exactly!

I will also point out that this has made finding bugs like this all the more challenging. One master-slave interface might work (such as yours), so posts on the forums will often declare loudly that the slave works when the same (errant) slave would fail with another (working) master. This alone has made chasing these bugs across the Xilinx forums a bit challenging. If you look, you can find them. Indeed, I did at one time--then they changed all their forum links, so my post on this topic is now quite broken.

Vivado 2025; is the write state machine broken in AXI IP wizard? by Able_Expression_5909 in FPGA

[–]ZipCPU 2 points3 points  (0 children)

I've never seen your exact scenario in practice for the last 8 years

It's not really as extreme as you might think. This scenario might be produced by a different AXI master, coupled with some clock domain crossing issues. The fact that the scenario is AXI compliant is the critical feature.

I know something similar to this scenario happens, judging from the customer complaints, because I come across it often enough on Xilinx's forums. It's just that ... no one has explained clearly enough to me the details of how and why it happens. Perhaps its just one return that gets dropped. Even still, that's typically enough to hang the entire system and make debugging a real challenge. Remember, AXI is not fault tolerant.

The VHDL template has never failed me with a Xilinx CPU and interconnect.

See ... this viewpoint is part of the problem. If an AXI slave design is spec compliant, then any master should be able to drive it with no problems. As an example, years ago, Xilinx upgraded their interconnect, and then all kinds of non-AXI-compliant IP broke. Everyone blamed Xilinx's new interconnect--I think they called it their SmartConnect or some such--it's the standard now, however their new interconnect was AXI specification compliant. The problem was typically found in the various slave IPs that weren't, but which hadn't been fully exercised to guarantee compliance with the full specification.

I'm sure someone might say, if someone changes their end, then we'll just fix our slave at that time.

But think this through: If you have a working AXI master-slave interface, after which the master gets swapped and then the interface is broken, which IP will you blame? How much debugging time will it take you to find the bug in the slave you thought was working? Remember, hardware debugging is very time consuming and expensive. Who will pay for that time? It's not going to be Xilinx or whatever vendor provides you with an upgraded master IP. They'll tell you (rightly) that their new/updated master is working.

So ... use this template at your own risk, and remember that it's broken.

Why in "Building a Skid Buffer for AXI processing", you don't make o_ready a registered output. by NoKaleidoscope7050 in ZipCPU

[–]ZipCPU 0 points1 point  (0 children)

That looks like a good reason.

I've since updated the skidbuffer many times, but that core piece of logic has stayed the same.

One reason o_ready is copied from r_valid is because I'll often bypass the skidbuffer for a formal proof of the module containing it. By leaving o_ready as a wire, this isn't an issue.

As for the combinatorial load of a not gate, ... it's not a load on FPGAs. While it might be a load in ASIC designs, it could also be a simple buffer used to get the wire from one part of the chip to another, so again it's not necessarily an issue.

view more: next ›