How to exchange data between PL and PS?

[lowena]

I have an Arty Z7-20 and I'm trying to figure out how to get arbitrary data from HDL in the PL to the PS, to be printed over USB UART. I've followed this tutorial and I understand how to connect GPIO to the PS and to print to a serial terminal, but I can't figure out how to send data from the PL to the PS.

Say I want to implement a simple CPU in the PL, that I can interact with through a serial terminal. How could I send, for example, the output of a program (like printing "hello world") run on the CPU in PL to the PS to then be output to a serial terminal, and vice versa (typing in the serial terminal to send data to the CPU in the PL)?

I want to do o this because I am interested in architectures, compilers, emulators and the like and would like to learn FPGAs by eventually implementing a CPU on the FPGA side. I've been stuck for so long by the USB UART being accessible only through the PS. I essentially just need a bridge on the PS to exchange data from the PL to the PC's serial terminal.

Thank you to anyone that can help!

[zygot]

15 hours ago, lowena said:

I essentially just need a bridge on the PS to exchange data from the PL to the PC's serial terminal.

Unfortunately, the FPGA vendors have decided that this has to be a very complex and challenging thing to pull off, even though it should be trivial. The best way to connect the PS and PL would be to write your own AXI slave or master IP. This is difficult and beyond the scope of many peoples ability. FPGA vendors like this arrangement because their limited function AXI IP uses up huge amounts of PL resources and confines many within the walls of the IP garden.

Putting aside questions as to why you'd want to do what you propose here's one perspective.

Generally, in order to connect the PS with the PL you need to use the AXI bus interfaces provided in the ARM hardware. There are exceptions and a simple UART is one of them. The PS has a lot of interfaces that aren't being used on most ZYNQ boards. One happens to be a 2nd PS UART. You can 'export' the spare PS UART through the EMIO through the PL. Normally, one would connect EMIO signals to PL pins but you can just connect the TxD and RxD to logic in your PL.

From an HDL point of view there are alternates to complex AXI infrastructure. You can instantiate a BRAM controller in your board design and add a dual clock BRAM with one side exposed to the PL. Your HDL just uses the BRAM as normal and your PS can do read/write operations like any other memory connected to the PS. You are still wasting PL resources on AXI infrastructure but it does ease your PL design burden.

While if makes no sense to me I understand why it might be tempting to have a design with an embedded hard ARM processor complex and an additional soft processor in the PL. Conventional software design is just a lot more familiar and comfortable than logic design. The FPGA vendors know this too and will make you pay an exorbitant price for the convenience. But that's the way technology has always been; fast, cheap, simple, convenient has always been over-priced.

15 hours ago, lowena said:

I am interested in architectures, compilers, emulators and the like and would like to learn FPGAs by eventually implementing a CPU on the FPGA side.

Here's a suggestion. Ditch the ZYNQ board. Buy an FPGA board like the ARTY-A7. Learn how to design logic in the HDL or your choice. It's like learning how to break horses. The first attempts will be a rough ride, but eventually you will end up having a greater appreciation for horses and a usable skill that doesn't rely on crutches like a MicroBlaze....

Edited December 20, 2020 by zygot

[D@n]

@lowena,

The "official" answer to how to move data from the PL to the PS is that you should build an AXI bus master in your PL design that can write directly to PS memory.  A program running in PS can then check that memory for data written to it, and act accordingly.  You'll need to beware of the data cache (turn it off--lest you read out of date information from within software), and the MMU (lest you write to the wrong memory address).  Once you've dealt with those, writing an AXI master becomes quite doable.

Xilinx will also try to push you towards using a DMA to move data from PL to PS.  Using a DMA is not a bad idea.  Just beware of the bugs in their S2MM (stream to memory) DMA implementation--lots of individuals have gotten hung up on those.  (Xilinx's official answer to their S2MM bugs is that they are misunderstood features--but that's a whole nuther discussion.)  There are also several ugly/nasty bugs in their example AXI slave designs--so much so that I'd recommend not using them.  Better alternatives exist.

Dan

[zygot]

I don't object to saying that writing an AXI master is 'doable', but I'd say that doable a relative term. From what I've read about the work that @D@nhas put into understanding the AXI bus specification and FPGA vendor implementations I'd say that this is no trivial endeavor. I'm always loathe to assert that something can't be done, seems like a guaranteed way to lose a bet. On the other hand betting that specific individuals couldn't do a robust job at it might be a good way to earn beer money. 

You don't need to use AXI bus DMA functionality. The ARM complex has a software programmable DMA engine that can be used nicely with PL BRAM.

Writing an AXI master or slave in an HDL is one thing. Packaging and integrating that IP into form that can be used seamlessly by the FPGA vendors'  HW/SW tools is another. So @D@n, what's the chance of seeing a compact demo of your IP that does that and can be replicated by user's of this forum using Vitis and Vivado? I'm absolutely sure that more than a few readers of the Digilent Forums would find it to be interesting and useful.

[D@n]

@zygot,

17 minutes ago, zygot said:

I'm always loathe to assert that something can't be done, seems like a guaranteed way to lose a bet.

Lol.  You won't find me putting money down for such a bet either.

17 minutes ago, zygot said:

Writing an AXI master or slave in an HDL is one thing. Packaging and integrating that IP into form that can be used seamlessly by the FPGA vendors'  HW/SW tools is another. So @D@n, what's the chance of seeing a compact demo of your IP that does that and can be replicated by user's of this forum using Vitis and Vivado? I'm absolutely sure that more than a few readers of the Digilent Forums would find it to be interesting and useful.

@zygot,

At the risk of taking this thread far off topic, let me ask, What sort of demo would you like to see?

I have an AXI performance measurement tool that needs to be tested out somewhere.  It's a solution looking for a problem at this point--much like the demo you would like to see.  So, again, what sort of demo would you like to see?  What particular items are you interested in seeing?  Things that would be relevantly useful in demonstrating?  I make no promises to implementing such a demo in the near future (my contract time is currently overbooked), but I'd be glad to have the suggestion for when I get a spare moment later.

Dan

[zygot]

@D@n, I sent you a message.

[zygot]

I recently posted a demo project in the Digilent Project Vault using an 8 pin pseudo-ram device. One of the platforms that I implemented the ram IP on was the Zedboard. You might find this interesting.

On the CMOD-A7 with a UART user interface:

ram IP used: 49 slices, 128 registers, 146 LUTs

user interface used: 134 slices, 146 registers and 238 LUTs

For the Zedboard I used the 'preferred' board design approach to have 2 BRAM controllers and 2 BRAMs, 8 32-bit control registers and 8 32-bit status registers using my own ZXI IP that I did many years ago. Functionally, the CMOD and Zedboard demos did the exact same thing ( note that I wasn't using the BRAMs in this implementation ). Here's the damage on the Zedboard:

the 2 BRAM Controllers used:  186 slices, 412 registers, 405 LUTs

the ram IP used: 52 slices, 129 registers and 150 LUTs

the control registers used 51 slices, 159 registers and 57 LUTs

the status registers used 41 slices, 161 registers and 39 LUTs

the SmartConnect that Vivado added to the board design used: 2627 slices, 8639 registers and 7425 LUTs

For the first iteration of the Zedboard implementation I had only 4 32-bit registers using the Xilinx AXi GPIO and all of the AXI utilization was significantly worse.

You can make of that what you want. One way to look at it is why worry about resource usage when your design doesn't need more? The other way to look at it is for a complicated design will Vivado leave enough resources left for my design after the AXI interface is implemented? Or perhaps more importantly, if I do a design that fits today and tomorrow I want to add functionality will I be able to do it with on the hardware that I started with? The last one is a question that those in industry need to consider.

 

Edited December 21, 2020 by zygot

[asmi]

I'd say if AXI bus master or AXI-lite slave is complicated for you, you'd better stay away from FPGAs at all as these are among the simplest things you will encounter. AXI spec is just a bit over 100 pages long (if you exclude ACE part), which is very small compared to some other standards you will have to deal with (803.2 is over 4000 pages, DisplayPort 1.2 is ~500, PCI Express 3 is ~800).

Full AXI slave is usually the most complex because you generally have no idea what kind of requests you are going to receive, and so you generally have a choice of either implementing it "good enough for Australia" (C) Dave Jones - meaning it works well enough for your specific use cases; or you will need to be fully compliant to the spec - and even though AXI VIP makes this task much easier to accomplish, it's still a good amount of work. Also there are some odd non-compliant AXI masters written by idiots who can't manage to comprehend specification, but will absolutely need to be used in your designs for some reason.

[asmi]

On 12/21/2020 at 12:18 PM, zygot said:

Or perhaps more importantly, if I do a design that fits today and tomorrow I want to add functionality will I be able to do it with on the hardware that I started with? The last one is a question that those in industry need to consider.

That is not an easy question to answer, because feature creep is real, and so you will have to know when to stop, call it "done" and ship. Otherwise you are risking to be stuck in perpetual "almost done" state and never actually shipping anything.

[lowena]

@zygot Sorry for the late reply. I've been trying a bunch of things to try to get anything to work. I'm trying to go with the UART1 through EMIO method, but I can't figure out how to connect my code to it. I've included my test code, a screenshot of the block diagram, and a ZIP of my project folder. I don't expect you to help, but if you or anyone else can I would appreciate it a ton. :)

When I try to generate the bitstream I get an "Unconstrained Logical Port" error for LED, which I don't understand. I know I must be doing something wrong but I don't know what...

 

module top(
    output LED,
    input clk    
    );
	 
integer counter;
reg state;

always @ (posedge clk) begin
    counter <= counter + 1;
	 if(counter >= 50000000 )begin
		counter <= 0;
		state <= !state;
	 end
end
	 
assign LED = state;	 

endmodule

uart.zip

[zygot]

12 hours ago, lowena said:

I can't figure out how to connect my code to it

Well, I'll offer one way, which is how I do ZYNQ designs. After creating the board design and generating the output products I tell Vivado to create a wrapper file in the project HDL, typically for me in VHDL. This wrapper then gets instantiated into my own toplevel entity where I can connect to any exposed signals that were made external in the board design. Usually, Vivado attaches IO buffers to these signals but will remove them and spit out warnings that can be ignored. You can look over an example here: https://forum.digilentinc.com/topic/20299-fun-with-phasors/

So, in your schematic above the first thing to do is make your UART signals external...

[edit] I forgot a sentence that I always add: When you have Vivado create your wrapper file make sure to de-select the default option that lets Vivado manage the wrapper code. You want to manage this to avoid unnecessary fights with the tools.

Edited December 23, 2020 by zygot

[zygot]

17 hours ago, asmi said:

I'd say if AXI bus master or AXI-lite slave is complicated for you, you'd better stay away from FPGAs at all as these are among the simplest things you will encounter.

Hmmm, I guess then that you'd suggest that Intel and Xilinx ( or it's new owners ) had better find a new occupation because they are purveyors of some really bad and or buggy AXI IP. I'd say that this is evidence that you don't have to be an idiot if you struggle designing with it. Let's face it most of the questions asked on this forum aren't from expert and seasoned FPGA developers. Yes, you are correct that there's no mystery in AXI or AMBA specifications; they are freely available. But I'd have to disagree with the notion that they are trivial to work with. The truth is that they are overly complicated and inappropriate for most FPGA design applications, unless of course they are required as is the case with FPGA devices having a hard ARM core complex. Both Altera and Xilinx could have provided a simpler and less complex hose between the PS and the PL but they chose not to because they are in the business of selling gates. If AXI was so trivial you'd think that companies who's income depends on it woulf be able to do a better job with it.

While any of the AXI versions might not be excessively complicated that doesn't mean that only idiots design bad AXI based logic and applications. 

In my experience it's rare for an FPGA designer to design logic to use an interface in all of its permutations and capabilities, unless they happen to be in the IP selling business. When creating IP with partial functionality it's sadly not uncommon to find that things were missed. This is more about professionalism and  a commitment to robust design over making money. Good engineers working for bad companies usually don't do good engineering.

While am on the subject it isn't just bus specifications that some users might find intimidating, basic concepts like clocked logic and resets are done poorly in many designs that I've seen. Some of us can do something about that and some of can't.

Edited December 23, 2020 by zygot

[asmi]

Again, there is nothing complicated in AXI bus design, it's used in pretty much all SoCs currently on a market which is why I suspect they choose to use it as well. Same reason why it was chosen for PL-PS interface because they can just connect it to internal AXI buses they already have in PS part.

And I also disagree about it being inappropriate. I use AXI and AXIS buses very extensively in my own designs, and overall very happy with them.

[asmi]

48 minutes ago, zygot said:

Both Altera and Xilinx could have provided a simpler and less complex hose between the PS and the PL but they chose not to because they are in the business of selling gates.

That is just nonsense. AXI bus by itself does not require any gates, if your core requires a ton of gates to connect to AXI, that's because your design sucks, not because AXI is bad.

[zygot]

1 hour ago, asmi said:

That is just nonsense. AXI bus by itself does not require any gates, if your core requires a ton of gates to connect to AXI, that's because your design sucks, not because AXI is bad.

Really? I guess that you missed what I posted above concerning the SmartConnect that Vivado insists must be used with it's own IP, using it own preferred design flow. Well, yes using AXI usually does end up using gates... and the need for larger and expensive parts, which is the whole idea. Can you write your own AXI IP and minimize slice utilization? Of course. Will anyone using the preferred board design flow have similar success? Not a chance.  I've written and packaged my own AXI IP which has served the purposes of the project that I've used them on so I'm not just expressing gas on this topic.

I'd modify your words to say that if your design uses a lot of gates then you're probably using the tools as Xilinx or Intel would prefer you do.

So, I'll direct the same challenge to you as I did to @D@n, post a demo project showing off your AXI prowess for the typical Digilent Forum reader's benefit for everyone to admire and learn from as well as see how trivial it is. Dan didn't reply to my explicit mail invitation because, as far as I can tell, he's never actually done a complete ZYNQ HW/SW design project and has a few holes in his understanding of what's actually involved. Calling other people idiots is easy. Directing readers to blogs that don't actually resolve a complete design that can be replicated is easy. Posting projects to the Project Vault with source code is useful. So, put your integrity where you mouth is.. show us what you got. ( I'm pretty sure that I've avoiding degenerating into the abyss that our first dialog sent us to but if not someone will be in touch ). A demo is worth a lot more than idle boasting.

For what it's worth, I never stated that AXI is bad. If a vendor is selling a micro-controller with a general purpose external bus interface knowing that adding programmable logic isn't likely a viable customer option, then sure an overly complicated and general purpose bus that the customer can hang high-performance and or low-performance logic onto makes sense. If the micro-controller is embedded into a large FPGA device then this make a lot less sense for the customer at least. At least provide one high performance simple connection between the PS and PL that doesn't serve a myriad of purposes; especially when there are so many other AXI paths provided. I'm just suggesting that the reason for not doing that has nothing to do with technical problems that ARM can't resolve.

Edited December 23, 2020 by zygot

[asmi]

16 minutes ago, zygot said:

Really? I guess that you missed what I posted above concerning the SmartConnect that Vivado insists must be used with it's own IP, using it own preferred design flow.

So don't use it. Nobody is forcing you to use it, right? You can use AXI Interconnect, which works with any masters and slaves.

18 minutes ago, zygot said:

Well, yes using AXI usually does end up using gates... and the need for larger and expensive parts, which is the whole idea.

That last part is nonsense. And you know it all too well to spread this conspiracy BS.

19 minutes ago, zygot said:

I'd modify your words to say that if your design uses a lot of gates then you're probably using the tools as Xilinx or Intel would prefer you do.

Don't place words into my mouth. I don't care what they do or don't prefer, what's important is what I prefer.

24 minutes ago, zygot said:

So, I'll direct the same challenge to you as I did to @D@n, post a demo project showing off your AXI prowess for the typical Digilent Forum reader's benefit for everyone to admire and learn from as well as see how trivial it is. Dan didn't reply to my explicit mail invitation because, as far as I can tell, he's never actually done a complete ZYNQ HW/SW design project and has a few holes in his understanding of what's actually involved. Calling other people idiots is easy. Directing readers to blogs that don't actually resolve a complete design that can be replicated is easy. Posting projects to the Project Vault with source code is useful. So, put your integrity where you mouth is.. show us what you got. ( I'm pretty sure that I've avoiding degenerating into the abyss that our first dialog sent us to but if not someone will be in touch ). A demo is worth a lot more than idle boasting.

I don't have time for that, too busy for customer's project atm, but I genuinely don't understand what's the actual problem? Is posting a read request over AR channel and receiving a burst over R channel is really that mind-bogglingly hard to comprehend? Is placing a FIFO at the end of R channel with it's WE signal tied to valid requires some sort of PhD degree? Or posting a write address over AW channel and bursting in your data over W channel from some sort of FIFO?

Can you dispense with this over generalized blah-blah-blah and tell me what exactly is your problem with AXI that you are unable to solve? And what would you propose as functionally equivalent replacement?

22 minutes ago, zygot said:

For what it's worth, I never stated that AXI is bad. If a vendor is selling a micro-controller with a general purpose external bus interface knowing that adding programmable logic isn't likely a viable customer option, then sure an overly complicated and general purpose bus that the customer can hang high-performance and or low-performance logic onto makes sense. If the micro-controller is embedded into a large FPGA device then this make a lot less sense for the customer at least. At least provide one high performance simple connection between the PS and PL that doesn't serve a myriad of purposes; especially when there are so many other AXI paths provided. I'm just suggesting that the reason for not doing that has nothing to do with technical problems that ARM can't resolve.

That whole part is wrong too. AXI is a high-performance general purpose bus, and since it's an industry standard, choosing it for interconnect makes perfect sense. For customer the advantage is that you don't need to learn dozens of custom protocols for each IP they need to work with, once you learn AXI, you are ready to work with any of them. If you don't need memory-mapped bus and would rather prefer stream - that's what AXI Stream bus is for, which is as simple as it gets. Zynq has some weird-ass "Peripheral Request Interface" to connect PL stuff to DMAC, but I don't think anyone actually uses it (at least I hadn't even heard about it until I actually started reading Zynq TRM), what you can (and IMHO should) do instead is to add an AXI DMA IP to PL and use it to stream data from/to memory.

[zygot]

I've been involved with as an employee or contractor with a awful lot of companies using a very diverse range of technology. I've yet to meet anyone who's mastered all of that limited set of technology. That doesn't mean the everyone I've met is an idiot or incompetent; it just means that none of them have mastered all of the those technologies. Early TV, the CD player, LTE and 5G rely on very complicated and often non-intuitive concepts and conjectures to work. Very few people have an appreciation for the tricks and details involved. Yet everyone has used them. Thinking that you understand all of the underlying principals of technology doesn't necessarily mean that you are smart, perhaps just not knowledgeable, nor does it make those who know little about them stupid.

I welcome challenges to things that I post on but I'm not too happy with assertions of competence or non-competence. If you think that I'm wrong about any of my assertions please post a reply; but be prepared to back up pure bluster with some evidence. I rarely direct my posts to seasoned expert engineers because these forums are for beginning users. The purpose of the forums is education and enlightenment, and perhaps to steer those with little experience toward a more fruitful path.

The original question was about connecting a ZYNQ PS to the PL so I don't think that anything said so far has been off topic. Yet, I think that it's necessary to state what should be obvious.

[zygot]

26 minutes ago, asmi said:

don't have time for that, too busy

Hmmm... thanks for the information, you just won me a lunch bet. Perhaps you can answer this question. Why is it that people who have time to engage in unproductive nonsense can't use the time to provide useful help.

Here's a suggestion. Instead of posting snarky remarks, just paste one of your AXI master Verilog source files here with a brief description of how you used it. That can't take up much of your valuable time and could help the average user grasp the topic.

Edited December 23, 2020 by zygot

[asmi]

1 hour ago, zygot said:

Hmmm... thanks for the information, you just won me a lunch bet. Perhaps you can answer this question. Why is it that people who have time to engage in unproductive nonsense can't use the time to provide useful help.

Here's a suggestion. Instead of posting snarky remarks, just paste one of your AXI master Verilog source files here with a brief description of how you used it. That can't take up much of your valuable time and could help the average user grasp the topic.

I can't post anything from my work, but I seriously don't understand what the heck is your problem. Do you want me to show you how to send a read request over AR channel? As in - "assign "1" to "arvalid", assign address to "araddr" set up other transaction parameters (arlen, arsize, arburst, etc) as required, wait for "arready" - that means requests is accepted. Then raise "rready" signal over read channel and look for "rvalid" signal which will indicate that you have valid data on rresp lines, which will tell you if request was successful or not, and if it is, the data you've requested will be on rdata lines. If your request was for a burst data, look for rlast signal which will signal the end of the burst.

What of the above is complicated, or unclear, or require "a ton of gates" as you seem to imply?

[zygot]

1 hour ago, asmi said:

but I seriously don't understand what the heck is your problem

I'm not the one asking for advice. My problem seems to be interference with my efforts to attempt to provide a good reply to the question that's the topic of this thread. That's not too hard to understand. Instead of engaging with whatever nit-picky details of my posts that bothers you, it would be helpful for you to either provide an alternate answer and route to a solution to the question or send me a personal mail message detailing your specific grievances. I'm pretty confident that asserting that anyone who is too stupid to write their own AXI IP shouldn't be doing FPGA development is not helpful advice. My problem shouldn't be a problem for @lowenatoo.

I don't post work written for customers as this becomes their property. Surely, you've done a few ZYNQ designs on you own time and have something to share. Instead of spending all of the effort you've spent so far on this thread responding to everything except the question you could have written a generic AXI master Verilog file, since you've done that so may times, to illustrate how easy it is. But the application details complicate the code expression don't they.

Personally, I don't often do ARM embedded designs and proprietary buses have no place in my logic, which is typically resource constrained. I have done enough ZYNQ work to know what's involved with using AXI but for quick prototyping or casual project I've never had the need to write optimized fully verified AXI-specific code; which doesn't mean that I haven't written AXI connected code that was usable to complete a project. As I've posted in other threads I've found the BRAM controller with dual clock BRAMs a convenient way to connect data between the PL and PS.  On the HDL side there's no beats or bus faults to worry about. Is it the optimal solution to all ZYNQ designs? No. Does it work without worrying about bus fault issues like some of the Xilinx AXI IP offers? Yes.

Anyone who has the time and interest can do a bit of spelunking about the Digilent IP source code as well as other places to help understand how to implement, perhaps good, perhaps, bad AXI IP. I don't do this often but @D@nhas a blog that nicely describes some of the intricacies of the AXI interface and potential issues though not a complete and useful example of how someone likely to post a question on Digilent's Forum can bootstrap off of for a solution to their particular project.

Edited December 23, 2020 by zygot

[asmi]

51 minutes ago, zygot said:

My problem seems to be interference with my efforts to attempt to provide a good reply to the question that's the topic of this thread.

I fail to see how your statement that AXI bus is difficult and "was chosen to waste gates" is going to be helpful to the OP.

 

53 minutes ago, zygot said:

Surely, you've done a few ZYNQ designs on you own time and have something to share.

I don't even have any Zynq boards. All my Zynq-related experience was in commercial projects. I prefer working with "pure" FPGA designs. Although that might change soon as I've managed to score few Zynq-030 chips for cheap, so will build a board if and when I will have enough spare time. Even these holidays I will be assembling boards for my customer, so no time for personal stuff :( I also got few Kintex-325 chips from the same source, so I'm really looking forward to the time when I can design boards for these things.

1 hour ago, zygot said:

As I've posted in other threads I've found the BRAM controller with dual clock BRAMs a convenient way to connect data between the PL and PS.  On the HDL side there's no beats or bus faults to worry about. Is it the optimal solution to all ZYNQ designs? No. Does it work without worrying about bus fault issues like some of the Xilinx AXI IP offers? Yes.

BRAM is good enough for simple cases, but often your IP needs to perform DMA - for example when you're designing an Ethernet peripheral, or some kind of streaming application (video, audio, high-speed DAC/ADC). You can choose to use existing IP to implement DMA portion of your design (this is how Xilinx commercial TriMAC Ethernet IP does it for example), or you can integrate simple DMA module into your IP (most PCI and PCI Express Ethernet addon cards use this approach). The latter tends to be more efficient for both resource consumption and optimizing data flow in and out of your IP, but it requires more work to implement, and there can be some serious pitfalls if scatter-gather functionality is required.

Another use case where BRAM is not very well suited is when you need to implement a register-based control interface via peripheral AXI lite bus, when register reads and writes need to have side effects (like writing 1 to start bit of control register causes some kind of processing in your IP to begin). For that the easiest solution is to just use AXI lite generator built into Vivado. I know Dan foamed a lot about how bad this auto-generated code is, but I can't remember a single case when I actually had problems with it (modified of course to suit my needs) in real designs.

[D@n]

@asmi

5 hours ago, asmi said:

I know Dan foamed a lot about how bad this auto-generated code is, but I can't remember a single case when I actually had problems with it (modified of course to suit my needs) in real designs.

I'm finding about one complaint in Xilinx's forums roughly every week to two weeks.  The complaint is typically from a user whose design is locking for what appear to be completely inexplicable reasons.  Digging further typically reveals that they are using one of Xilinx's demo designs--either the AXI-lite or the AXI (full) one.

Whether or not you run into one of these problems really depends on how you configure the interconnect.  If you configure it for "area optimization", you won't be likely to see the bug.  Another key criteria has to do with how the bus is driven.  One user experienced lock ups when issuing an unaligned access from a MicroBlaze CPU.  (Help!  The FPGA engineer left the company, and I'm just the S/W guy but ...)  Others have run into problems when trying to interact with one of these designs using a DMA of some sort.  Another recent issue had to deal with connecting a 64-bit AXI bus to a 32-bit Xilinx generated demo peripheral.  It seems a key to triggering either bug would therefore be two accesses in close succession--much as I outlined in my write-ups.

As you can see, whether or not the bug gets triggered is highly dependent upon the use case.  Worse, when attempting to apply hypothesis testing to find where to look for the bugs (if I change A, the design fails, therefore the bug is in A somewhere), you'll often get sent looking for the bug in the wrong part of the design.

Dan

[zygot]

10 hours ago, D@n said:

Help!  The FPGA engineer left the company, and I'm just the S/W guy but ..

When someone only gets involved with part of a design project, like doing HW design and never doing SW design in actual use cases, they can be under a false impression that everything they do is perfectly wonderful. I've seen this over and over. Even if working at the same company the SW team might just find a workaround and problems never get back to the HW designer. Often the workload and project schedule don't leave time for sorting out these kinds of issues. Sometimes there's just inter-departmental rivalry or friction. You'd think that this couldn't happen but it more common than a rational person would think that it could be. In some companies the designers never do any verification and it's left to the verification engineer to find the problems and fix them. Feedback on how your designs are performing is an important part of the design process. To my way of thinking even if you are a HW design specialist you need to be doing enough SW design to 'close the loop', at least to dome degree, particularly if the design is so tightly coupled to SW as AXI buses are for ZYNQ.

In a similar vein, if someone is going to provide guidance and suggest solutions to a struggling FPGA beginner then they need to be able to understand the complete flow that such a person would use, even if that's not one that they use. Or they could explain in detail a better development flow. This is what makes answering questions like the one that prompted this thread so difficult to address. If your response to a question asked on this forum is all about you, then it is unlikely to be any benefit to the person needing advice. I'm betting that very few people asking for help on this forum has any interest in writing AXI HDL code. In fact my impression that the draw for using a ZYNQ type device is that they can replace the complicated HDL design flow with something more comfortable and friendly like software design. That's why I try and post answers that I hope are suitable and usable for the person asking for help. This usually requires making assumptions about their level of skill and knowledge and interest in the subject.

Edited December 24, 2020 by zygot

[zygot]

On 12/21/2020 at 10:29 AM, D@n said:

At the risk of taking this thread far off topic, let me ask, What sort of demo would you like to see?

I sent Dan an email with a description answering that question. He's read the mail but so far has chosen not to make any sort of reply. I mention this because it seems to be germane to my previous post on this thread. Until that changes we are left to presume what that means. I'm disappointed if no one else is. Anyone who's tried going through the design flow favored by Xilinx and Digilent, particularly for ZYNQ projects, know that there are serious issues involved if one wants to do real world designs.  I suppose I should start a new post thread discussing roadblocks to success that FPGA vendors throw in the way of customers who want to nudge the odds of success more towards themselves rather than the vendors. At least then anyone wanting to can excoriate me to their hearts content without muddling the basis for the thread.

[D@n]

@zygot,

1 hour ago, zygot said:

I sent Dan an email with a description answering that question. He's read the mail but so far has chosen not to make any sort of reply

Yes, I have read your message.  I'm not sure I'm ready to respond to it, and so I have not.  Let's just say I'm still mulling it over.

1 hour ago, zygot said:

I suppose I should start a new post thread discussing roadblocks to success that FPGA vendors throw in the way of customers who want to nudge the odds of success more towards themselves rather than the vendors

Go for it.  Perhaps the discussion that follows (if any) will help me form an opinion one way or another.

Dan

 

[zygot]

7 minutes ago, D@n said:

I'm not sure I'm ready to respond to it, and so I have not.  Let's just say I'm still mulling it over.

1 hour ago, zygot said:

Hey, that would have been a sufficient reply. You're generally responsive within the constraints of your workload. I'm happy to knock your concerns around with you if that will help.