Introduction, hello!

[mor.paul]

Hi,

I bought an Eclypse Z7 two weeks ago to record forces and outputs from sensors for an mechanical impulse instrument I'm building.  My main reason for posting is to get some help with problems that come up with the Z7.  Truthfully, I thought I'd be running by now and getting some test data from the impulse tester.  I'm going to ask my questions in another thread.

Thanks,

Paul

 

[zygot]

Hi Paul,

The Eclypse-Z7 uses the same part essentially as the good old, almost ancient, Zedboard ( do FGPA boards age like our canine friends in people years?). That board had a few organizations supporting it. Doing FPGA development using Xilinx's preferred board flow design method is painful and hard to maintain code through toolset version changes. The ZYNQ just adds more tools into the mix. It's hard for a lot of companies to keep up, especially if they are all in on the one preferred Xilinx design flow. The low level Zmod drivers are usable. Both Digilent pods are well designed. So far, customers who've posted success storied about the Eclypse-Z7 have been using the bare-metal software approach and going around the limited AXI based IP. I can only refer to posts that have been made. Someone around here should have some helpful ideas tor problems you've been encountering.

[mor.paul]

Hi Zygot,

Thanks for the email.  I bought this board because of my positive results using the Digilent the Analogue Discovery O-scope.  With my limited budget for the project I'm working on I thought the Z7 would give me the ADC''s I need.  I am a materials scientist not a software developer.  Coming from outside the field I am curious about the jargon used to advertise these boards.  What do the terms "Bare metal" and "AXI IP" mean?  I have been thinking about this for the past week or so.  When I look at the example code I do not see a major difference between the bare metal example and the linux.

Paul

[zygot]

8 hours ago, mor.paul said:

Hi Zygot,

Thanks for the email.  I bought this board because of my positive results using the Digilent the Analogue Discovery O-scope.  With my limited budget for the project I'm working on I thought the Z7 would give me the ADC''s I need.  I am a materials scientist not a software developer.  Coming from outside the field I am curious about the jargon used to advertise these boards.  What do the terms "Bare metal" and "AXI IP" mean?  I have been thinking about this for the past week or so.  When I look at the example code I do not see a major difference between the bare metal example and the linux.

Paul

OK, I looks like you are at the beginning of the learning curve. Not problem, everyone starts there.

First, I also own the first version of the Analog Discovery. It's an excellent product that's well designed and well supported to be used as an inexpensive instrument. It also has limited capabilities. There are other similar products like the Red Pitaya that are based on the ZYNQ FPGA and a bit more flexible. These are supposed to be easy to use and versatile, and they are. The Eclypse-Z7 is very similar to the Red Pitaya as it's build on a low end ZYNQ FPGA as well but much more flexible. Unfortunately, Digilent has advertised it as being more in the class of easy to use 'instrument' products like the two already mentioned. It's not. Digilent has been struggling to identify what exactly the Eclypse-Z7 is much less to provide support for it.

The ZYNQ is a familty of FPGA devices that have an embedded hard ARM processor complex in it. The devices are probably better thought of as ARM processors with connected FPGA. What connects the PS processor complex and the PL FPGA logic are a number of AXI busses. The device user must create a board design that has a ZYNQ Processor Subsystem and a minimal set of AXI based PL structures. The ARM complex can control external devices like USB ports, Ethernet ports, DDR memeory, etc. The PL is connected to mostly GPIO which can be driven by the logic design elaborated in it. This logic can be designed using Xilinx IP in the board design or using an HDL like VHDL or Verilog.  I don't want to get too far in depth at this point.

Once the user has created a bitstream for his hardware design in VIvado he still has to create a software application for the ARM PS. In Vivado version previous to 2019.2 this was done with either the SDK using Xilinx standalone (bare-metal) software libraries or an RTOS. The alternative is to build the PS Application on a Linux distribution. The Linux development route cna only be done on a host PC running on certain Linux distributions. The most recent versions of Vivado use VItas for processor software application development. It corrals a number of different and separate software development tools into one big tool. Unfortunately, developing a ZYNQ PS Linux application still requires a Linux host.

So, that's the really terse introduction to a very complex design flow. 

You obviously bought the Eclypse-Z7 with the expectation that it was going to provide the same experience as the Analog Discovery. That's not your fault because Digilent has made some wildly inaccurate marketing claims about the Eclypse. I complained about this in a post quite a long time ago and got a reply from someone who assured me that they were going to correct inaccurate marketing claims.

I own both the Analog Discovery and Red Pitaya products so I know how they operate. My expertise is FPGA logic design from before the days of embedded hard or soft processors so I know the tools and development flow very well. The Red Pitaya might be a better fit for your application and experience level. Digilent has historically marketed to the student and academic market and has gotten away with being a bit short on support for their FPGA board products in terms of providing easy to use and integrate IP into user applications. A lot of things went sideways with the Eclypse-Z7 in that regard. That doesn't mean that the hardware isn't useful or inadequate for many user applications. What the Eclypse-Z7, and a few of their newer boards introduce  is support for the SYZYGY plug and play specification that, in theory, allows for full use of the XIlinx FPGA IO capabilities, including ADCs and DACs. In reality, the ZMODs don't need SYZYGY but that's another discussion. I've executed a dozen or so designs on the Eclypse-Z7, mostly experimentation, as I rarely use ZYNQ devices. Digilent just hasn't created a design environment for a Linux PS application flow that's worth it to me to develop an application on yet. For one thing, it can run Digilent's build of Debian Linux but you can't run an application using your design from it's OS. It doesn't provide sufficient support for using the Ethernet port, which is the only way to develop applications using Xilixn tools. I could continue listing short-comings but this isn't the place or time.

On the Red Pitaya you can build and run user FPGA applications and it has a robust Etherent based interface that's useful as far as it goes. Getting data into and off of the instrument is another matter. And that, in a nutshell, is the problem with the ZYNQ development process. It's so complicated and difficult that even FPGA board vendors can't figure out how to affordably develop their own products to be easy to use for their customers. What Digilent promoted the Eclypse-Z7 as is a worthwhile vision but it's no where close to being a reality; and you won't find that vision being provided by anyone else either. The blame for this falls on the shoulder of Xilinx. But they have their own struggles writing software that provide toolset functionality. It's all a big mess. Intel is worse at it, and is... well,  Intel to boot.

Sorry, this got a bit winded but I tried to address what I see as your quandary.

What Digilent has failed to realize, at least in my view, is that working people don't have time to mess around trying to correct deficiencies and fight with arcane and complicated development processes. They have their own deadlines that need to be met. When your customers are students you can make them happy with partial support. If you are going to market to working engineers, even ones who are quite adept at FPGA development, these customers won't tolerate having their time wasted because they have bosses who aren't interested in why deadlines haven't been met, only that they haven't. So, the professional market has different expectations and demands. If, you market your products in a way that clearly defines the limitations of support, then perhaps your customers will buy your stuff and be still content. If your professional customers have to overcome obstacles that delay their schedules, or worse yet discover that a feature can't be used without considerable effort or buying IP licenses, then they will not be happy.

[D@n]

@mor.paul,

What is AXI?

As @zygot said, it's the bus protocol the ARM within the Zynq (sometimes called the PS, or Proccessing Side) uses to communicate with the FPGA logic (also called the PL, or Programming Logic.)  More on that in a moment.  For now, understand that FPGA logic is not software.  It's reconfigurable hardware.  When building FPGA logic, you'll be using tools to route wires within a chip, to configure flip-flops for your logic, and build designs out of Look-Up-Tables, or LUTs.  LUTs are boolean functions, take N-bits in, produce one bit out.  The terminology changes a bit as well.  Software engineers write programs.  Hardware engineers build designs.  Another surprise to software engineers when dealing with hardware, is that the minimum data unit is one bit and not 8-bits, but I digress.

Unlike @zygot, I'm still working on my first Zynq design.  I've done many basic FPGA designs on chips without the ARM processor within it, but that Zynq processor can be a challenge to work with.  I'm personally not sure why Zynq is a recommended device for beginners, given the challenge's I've  had so far when working with it.  Most of what I know, therefore, comes from helping users with questions on forums such as this one, Reddit, or Xilinx's forums.

Before discussing AXI, let me define a bus protocol in general: A "bus" in this context is something that allows a CPU to talk to memory and peripherals, and no longer the original concept of a group of wires that might be shared between multiple electrical drivers.  In this case, the CPU issues either read or write commands in response to load or store assembly instructions.  Each command comes with an address of where to read from or write to, and write commands also come with the data to be written to that address.  A simple C statement, like: "volatile int *ptr  =0xa0..., a; a = *ptr;" will cause a read command to be issued from the ARM to the PL.  (Getting the address right is important, but also something I'm not going to address here and now.)  A similar C statement, such as, "*ptr = a + 1;" will cause a write command to be issued across the bus.  Well, okay, neither are quite true--there's the issue of the cache, where the CPU reads values into a cache to speed up its operation and then only writes values out again later.   If I recall correctly, the ARM cache is disabled by default for the addresses that talk to the PL, but you can turn it back on if you want higher speed transactions.  The key here is that you, as the hardware designer, get to choose what you will do when a request comes in to write to a specific address or read from a specific address.  While you can make the value at an address act like memory, it doesn't need to do so.  You could make a peripheral that, upon every write, sends the character written to a serial port, or reads the most recent character received from a serial port.  This is sometimes called Memory Mapped I/O, and you can consider the entire memory map of the PL to be a reference to memory mapped I/O.  Again, you get to decide how it behaves.

That's the good news.

Here's the bad news:  AXI is not a trivial protocol.  It is neither simple nor easy to master.  Call me a dunce if you want, but it took me many months before I finally figured it out enough to be confident when working with it.  (Part of my problem was that I was trying to build a rather complex design, and didn't start out simple ...)  It doesn't help that Xilinx's example logic has been broken since at least 2016, and risks locking up your design--at which point you'll have no idea why it was failing.  This leads to a common situation I call FPGA Hell, where the chip doesn't do what you want and you have no idea why not.  Trust me, it's common.  As of Vivado 2020.1, they still haven't fixed their demonstration designs despite the fact that all of their instructional material uses them.  (You can find "fixed" example designs on my blog for all of the broken demonstration designs but their AXI-stream master.  Check out the topics page and search on AXI if you are struggling to find the articles.)

Some of the challenges associated with AXI include "back pressure", the idea that the slave can't return a response to a request from the CPU (actually the bus master) until the bus master is ready for it.  (This "feature" breaks Vivado's demonstration designs if it's ever triggered.)  A second challenge is that AXI permits burst requests, such as for 1-256 items at a time, but bursts can't cross 4kB boundaries.  A third challenge is that every request is tagged with an ID, and that responses for requests with different ID's may be returned out of order.  (This also breaks Xilinx's AXI full slave demonstration design.)  A fourth challenge is the idea of "narrow bursts"--something I discuss on my blog, also broken in Xilinx's demonstration design.

Suffice it to say that AXI is a non-trivial protocol.  It also reads like it was designed by committee, rather than by the engineer that needed to use it, since it has so many bells and whistles to it: Quality of Service guarantees, Cache coding that ... doesn't relate to the CPU's cache, Protection fields that just aren't well defined, a method for atomic accesses that really complicates CPU design and much more.  Someone is making a lot of money helping people deal with this complexity and it's not your beginning FPGA developer.

Xilinx has done their level best (or worst, you decide) to help by creating an IP integrator together with the illusion that you can just compose a design out of component parts.  This is sold as an "easy" method of design.  What they don't tell you is that many of these component parts are encrypted black boxes, making them very difficult to debug and work with.  Indeed, this seems to be a majority of forum requests: "I'm working with IP XYZ, and my design isn't doing what I expect, what's wrong?"  Other components which are not black boxes have bugs within them that the unsuspecting user will need to work around (ethernet-lite, s2mm data mover, etc.)  If you find yourself in this situation, make sure you grab a trace from within your design "showing" or "illustrating" the problem when you post it--it will make debugging across a forum a lot easier.  (Yes, I've built my own capability to do this.  You don't need to build your own, or even use my capability here, Vivado's seems to be much easier to use--even if not quite as capable.  For example, I once grabbed a compressed trace containing several minutes of data from within one of my designs ...)

To make matters worse, most of the instructional material for Verilog/VHDL design doesn't really discuss how to debug a broken design.  They'll tell you how to build a design, but not necessarily how to build a design and guarantee that it will work when you get to hardware.  This is a problem, given that hardware is much harder than software to debug: you don't have access, for example, to every variable within a debugger.  At best, you can blink an LED, or capture a "trace" of signals describing what goes on within a portion of your design for a thousand clock cycles or so.  This means that you, as a designer, need to learn early on to formally verify your designs, to simulate them, as well as how to blink LEDs and extract traces from within a broken design.  (Why "formal verification"?  Because Xilinx's Verification IP won't reproduce the bugs in their designs, leaving you believing that your designs work when they do not ...)

Yeah, I suppose that's a long winded welcome.  Hopefully it gives you a bit of a reality check and some helpful expectations management.  If you are still excited, then welcome to the forums!  You'll find other users like yourself here.  Some, like myself and @zygot, quite opinionated.  I figure that's a good thing.

Dan

[mor.paul]

@zygot and @D@n,

Thank you for spending the time to explain some of the terminology.  When I have some time to relax I reread your emails again.  At the moment I'm thinking about the SDK.

I have a mechanical test instrument that works when connected to a scope.  My problem is that the number of samples and bits is not quite good enough for me.  For me it looked like the Eclypse system would fit the bill, it has 2 ADC boards at 100 MSPs.  Based on what I see with the ADC demos is they don't work out of the box.  I have loaded and reloaded things, checking my work along the way.  Today when I switched to the ADC linux demo, using projects reloaded from the repository I end up with 7 errors and one include path not found.  The bare metal demo doesn't seem to have build errors, but when I run it I can not get any output....  It would help if I had a debugger working.  I have attached a screen print of the errors.  In the next reply I'll post how my system works attached to the scope.

Thanks,

Paul

 

[zygot]

@D@n,,

Yes, opinionated we both enjoy the difficult and challenging enterprise of FPGA development. Our criticisms are meant strictly to be constructive, even when born of frustration. I've been a dedicated user of Digilent products from before they ventured into making their own name branded products. I hope to continue to do so for a long time.

There's no two ways about it. Logic design using programmable devices is complicated. All of the programmable device vendors know this and have tried to encapsulate the process into a more palatable and less daunting exercise for customers. The devices are always getting more complex and the tools aren't keeping up. It doesn't help that their marketing departments have chosen to skew their tools to their advantage. It's always been that way and I see no escape from that pattern. Some people have the time and energy to spend on becoming competent with the development skill sets and some don't. As @D@n and I have pointed out expectations have a big impact on experience here. Certainly, end users of FPGA based products should expect a reasonable idea of what they are getting into with their purchase. Even seasoned FPGA engineers can get misled as to whether or not a product is a suitable platform for a particular product. I know this form personal experience.

On a side note there are FPGA based products in which the user doesn't have to know anything about FPGAs or how to develop with them. The Analog Discovery is one such product. Most of what Digilent makes on their own initiative ( these don't include the Analog Discovery or Zedboard ) are geared as strictly development platforms for engineers who are experts in programmable logic device design or students. I can see how it would be easy for someone not at all familiar with this to be confused with who the target customers are for most of these products.

Actual instrument vendors may well be FPGA based without the customer even being aware of it. But they have to provide detailed specifications which they are obligated to meet as well as pass a variety of governmental testing requirements. These products have a correspondingly higher cost to go with that responsibility. If you read the disclaimers for FPGA development products form Xilinx or Intel your eyes will glaze over. Smaller companies don't have the same legal resources compelling them to follow suit.

[D@n]

@mor.paul,

Those errors don't look familiar to me.  (Which doesn't really tell you much.)  You might need to do some digging there.

I will point out one thing: Digilent, and Xilinx for that matter, have had problems with user demonstrations.  The root cause of these problems tends to be Vivado's relationship with project management.  IP changes from one version to the next.  Interfaces change from one version to the next.  Each new revision risks making demonstrations made from the previous revisions obsolete.  Indeed, this is also a problem with a lot of instructional material.  In general you can trust the RTL sources from the past, but not necessarily the standards of things they interact with, to be stable.

One common solution Digilent has often given to these problems is to tell users to use a particular download for success.  When I met with one of their engineers some time back, they recommended the last release of the year as the one with the fewest bugs in it, so you might wish to try the design in 2018.3 to see if it still has bugs.  (I'm not going to recommend 2019.2, where they introduced Vitis.  Note the dates on this Xilinx forum post, from initial complaint to final Xilinx response.)

Dan

[zygot]

20 minutes ago, mor.paul said:

Based on what I see with the ADC demos is they don't work out of the box.

I've been doing FPGA development for over 20 years. I;ve been doing ARM based FPGA development as long as they've been available from every vendor.

It took me a good week to replicate the bare-metal demos on a WIN10 PC. I have Ubuntu installed on a separate disk of the same PC and it took me another couple of weeks to build the Linux demos. Your approach is correct. Try out the demos to see how things are supposed to work.

All of my problems were due to the complexity of the demo sources from Digilent. Their Git repository for the Eclypse-Z7 is difficult to work with. It's branched and you have to figure out what branch you need before cloning a repository. They provide inadequate and incorrect documentation both on the Git web pages in in their own documentation. Just a few days ago I stumbled trying to use one of the repository branches because I forgot to specify a branch. To the user you can start with the main page for their company wide repository and find what you think is what you want only to clone the darn thing and not have what you want. Digilent has no formal QA for software development, farms out designs to students without proper oversight, and  refuses to demand that developers who contribute to the Git provide any sort of documentation as to what the contribution does or corrects. It's a problem.

You have to read all of the arcane Digilent git documentation carefully to have any sort of success with the Ecypse-Z7. You have to clone the correct branch to get the sources for the demo you want. You have to work out how to get around the Digilent documentation errors. ZYNQ software is complicated. Digilent has just made it more complicated. Trying to build the Digilent demos without any experience with how the SDK works is an almost insurmountable hill to climb. There are a lot of little details that need to be understood. The SDK eclipse IDE, which is a custom version of a well worn Linux based development platform is not easy to master.

[zygot]

I should point out that since my first venture into working with the Eclypse Digilent has made some corrections. In theory, you can use an image for the Debian OS to build the Linux demos on a WIN10 host. The early repositories had a problem that prevented this and should have been corrected by now. I can't confirm this because I haven't tried again since. If you want to build you own application that doesn't use the demo code then you likely have to be using a Linux host. I haven't found an impetus to try doing that, mainly because there;s not enough development to allow PL configuration and application execution on the Eclypse-Z7 OS build to make it worth the time and effort.

The errors that you show are likely due to issues with how the project has been configured or a problem with reading the image libraries. Deciphering the mysteries of compiler error messages has always been sort of an art form and varies from compiler and IDE to compiler and IDE. The Digilent documentation has a lot of errors in it with regard to getting the demos working.

Have been able to run the demos on the Ecypse-Z7 running Linux? The answer is no and that should be telling you something.

[mor.paul]

Hi,

I took some pictures out of some of my activity reports.  Sorry if the quality isn't the best I can do.  I usually work in windows, but I'm currently in ubuntu.

The system sends a 1000V pulse to the piezo electric transducer.  While going to 1000 v the transducer expands 150 microns, after the pulse the system discharges to 0V while contracting.  I plan on putting a sample in there that deforms at low forces, while deforming some boundaries move and the magnetic field orientation from the sample changes by 90 degrees.  I just need to read the voltage to the piezo actuator, the force transducer and a couple of magneto resistive sensors with the electrical output should change when the magnetic field moves by.

Paul

[mor.paul]

FYI, I started with windows.  I went back to it this morning, but I have not figured out how to recursively reload the github projects.  I can only handle one fire at a time.  I guess I'll die with ubuntu.

Paul

[D@n]

@mor.paul,

Sounds like a fun project!

Dan

[mor.paul]

@zygot

Thanks for the warning on the repository.  I guess I assumed using the cmd for cloning the demos was up to date.  I just noticed in the linux demo the program writes to a file, without making a directory or using a fopen() to begin writing to it.  I also have not noticed a fclose() for it.  I was thought most people open a file, write to it and then close it.  I created a directory with a file that the demo plans on writing to.

Anyways, I got a good laugh at your observation about git hub.

Paul

[zygot]

@mor.paul,

I am no fan of Ubuntu or it's user interface but this is one of the OSs supported by Xilinx.

First off you seem to be needing a much longer sampling period than Digilent currently supports for the Eclypse. Digilent only let you capture 16383 ( yes not 16384 ) samples per channel. If you ditch the Digilent AXI IP you can increase this to 128K samples per channel. At 100 MHz 16383 samples spans a period of about 163 us.

There are alternate SYZYGY platforms that don't have this limitation. I've used the both the ADC and DAC ZMODs with the non-ZYNQ Opal Kelly XEM7320. Digilent also makes the USB104-A7 that isn't ZYNQ based. Either of these platforms are much more suitable for what you want to do. Unfortunately, you will have to learn how to do logic development using an HDL.

I've posted a XEM7320 with 2 ZmodADC1410s that can capture a full 256M samples on 4 ADC channels. But it's an all HDL design. It was a lot easier to accomplish than any of the Eclypse-Z7 designs that I;ve done so far.

 

[mor.paul]

@zygot

Yeah, I was reading through your posts from the last couple of days.  Why would one sell a board that can only handle 3FFF -1 pieces of data.  I'm a little confused why this is so....  doesn't the Z7 board have enough memory?  I was hoping there would be a way to do DMA 's to move the data out of the capture buffer.  Anyways, I've got two more months on my research contract at the Czech Academy of Science.  I might need to borrow some equipment from another lab here.  Afterwards, I plan on taking a three month vacation and then retiring.

 

Paul

[zygot]

In contrast to the Eclypse-Z7 Opal Kelly created the Brain-1 ZYNQ platform when they created SYZYGY. For their demos they use a web page server as an interface and you can  configure the PL from the Ethernet interface as well as run demos. It has the issue that it couldn't do both ADC and DAC demos concurrently. Opal Kelly hasn't put any investment into the Brain-1 since release but they had a better strategy than Digilent, just never completed.

I have yet to see a ZYNQ based platform where you can do configuration, application execution and data upload and download from within the Linux OS. This is due to the FPGA vendors control over Ethernet IP and the lack of expertise on developing Linux based Ethernet applications. The Red Pitaya comes closest to being usable but it too is web page server based and doesn't allow for transferring data between the instrument and PC host. Quite a large oversight I'd say. Did I mention that doing actual FPGA Linux development is difficult and expensive?

The Analog Discovery has two advantages. 1. It's not ZYNQ based. 2. It has a USB 2.0 port that's easy to write applications for and transfer data between the instrument and host.

[zygot]

Just now, mor.paul said:

Why would one sell a board that can only handle 3FFF -1 pieces of data.  I'm a little confused why this is so....  doesn't the Z7 board have enough memory? 

It has nothing to do with ZYNQ, the board design limitations or anything intrinsic about FPGAs. It's purely the result of poor design decisions made by the developers at Digilent. Did they forget to mention that limitation in the sales blurb?

Your question begs for a longer discussion but I'm spent for the moment.

[D@n]

@mor.paul,

4 minutes ago, mor.paul said:

Why would one sell a board that can only handle 3FFF -1 pieces of data.  I'm a little confused why this is so....  doesn't the Z7 board have enough memory?  I was hoping there would be a way to do DMA 's to move the data out of the capture buffer.

Every Zynq board I've seen has plenty of memory to be used.  There's also an AXI3 incoming port to the Zynq, which your design can use to write to the SDRAM memory on board.  Indeed, this is a common use case.  You just need to use an IP to write your samples to memory.  Xilinx has a "data mover" IP they use for this purpose.  The idea is that you configure this IP to transfer data to memory, and then off it goes.  You just need to feed it with 1) an AXI-stream containing the data to be saved, 2) the address to write to, 3) the amount of data to write, and 4) a start command to tell it when to start.  Beware there are some unexpected "features" when using this IP--for example, it will stop transferring on TLAST and it will lock up if you give it data before it's properly configured, but in general it should work well enough for you.

I have some of my own designs to do the same, but haven't yet tried integrating them with Vivado's board design.  This design, for example, acts like very much like a scope--saving data to memory until some holdoff period following a trigger.  It's designed for debugging an FPGA design where you know where and when things go wrong, but not necessarily what led up to them.  Here's another that works/acts very much like Xilinx's stream to memory (S2MM) data mover, with the difference that 1) it leaves TREADY low when you aren't using it, and 2) stops after the given number of samples are transferred rather than on the TLAST signal.  (These are AXI stream signals.)  Indeed, my S2MM converter was tried recently in a comparison with Xilinx's and (much to my pleasant surprise) it "just worked". 

Using a stream to memory approach like any of the above will require some ARM software.  Specifically, you'll need to pay attention to 1) make certain that the physical memory you are writing to is in a known virtual address location, 2) that the memory isn't cached at the time of the write, and 3) some method for getting the samples from your design to a nearby computer (Ethernet?).  Some of this is done for you when working with Xilinx's examples, some of this you'll still need to do on your own.  The good news is that, again, this is a common enough operation.

Ideally, you should be limited by the size of the SDRAM, but practically you'll be sharing it with Linux so ... there's a limit to how big of a memory area you can copy.  On the other hand, if you dumped the Linux, you could store to a larger area but then you'd need to more work to figure out how to control the network driver so that it would send data using a known protocol.  It's all about compromises and tradeoffs like any other engineering field.

Dan

[zygot]

1 hour ago, D@n said:

Ideally, you should be limited by the size of the SDRAM, but practically you'll be sharing it with Linux so ...

To my limited brain capacity, if I were to design a board that shows of the awesomeness of SYZYGY, Series7 IO, and my SYZYGY pods I'd let the logic have its own DDR designed to support a pretty high sustained data transfer rate. I wouldn't even think about ZYNQ unless I knew that I could complete the whole design concept, and then the PS would have its own DDR. Personally,  I think that there was a failure to do the correct homework and oversight needed to pull off a SYZYGY board. One thing for sure is that your first decisions will ripple through every subsequent decision and constrain choices down the oroad. I still think that they should have made a Genesys SYZYGY board with a USB 3.0 interface on it. That would have been awesome. Unfortunately, the number of ZYNQ based boards with a separate DDR for the PL are hard to come by, but this is well worth the extra price in terms of ease of use for customers. There's just no justification for PL data to do through AXI busses to a single PS DDR for high perfromance designs.

Why would anyone enter a marathon and run 25 miles only to decide to bail on the last couple of hundred yards to take a lunch break and go home. The mystery of corporate machinery.

Ideally, you should be limited by the size of the SDRAM, but practically you'll be sharing it with Linux so ...

There are so many details that were missed in the Eclypse-Z7 specification phase.

 

[zygot]

I forgot to mention what I would do in your position. I have a 4 channel digital oscilloscope with a 70 M sample capture memory and 300 MHz bandwidth. It's pretty easy, using the scopes' software to capture and download in text or binary format samples covering a arbitrary period of time using any Fs and then use software to extract the signal period of interest. It's also a lot easier to calibrate a scope  to NIST standards, set gain, coupling, offsets, etc. It's also a lot easier and faster to view preliminary capture data so that you can make sure everything is set up correctly before taking final testing measurements. The Eclypse-Z7 is useful, but isn't a good substitute for a decent scope. if you can borrow a scope then you can retire earlier...

[mor.paul]

Thanks, for the input on the scope.  I spent this morning working on a monthly report and this afternoon working on errors related to include paths and errors generated from the header files.  I basically think my Xilinx SDK paths in the project folders are not set right.  If I knew what directory the right files were in I'm pretty sure I could the build settings and compile.  Here are the files that are having problems:

/usr/include/bits/floatn.h:75:70: error: unknown machine mode ‘__TC__’

/usr/include/bits/floatn.h:87:9: error: ‘__float128’ does not name a type;

/usr/include/stdlib.h:152:8: error: ‘_Float128’ does not name a type

/usr/include/stdlib.h:245:4: error: ‘_Float128’ has not been declared

/usr/include/stdlib.h:330:8: error: ‘_Float128’ does not name a type

src/zmodlib/ZmodDAC1411/subdir.mk:18: recipe for target 'src/zmodlib/ZmodDAC1411/zmoddac1411.o'

You wouldn't think these header files could cause any heartache

Time to head out.

Thanks, Paul

[zygot]

Yeah, I don't remember the exact issues that I had with recreating the Linux demos on WIN10 but I'm betting that the SDK was unable to reference the OS library headers from the repository image that you got from Git. If you were doing this on Windows, then I'd day that Digilent hasn't come through with correcting the compression problem they had. On Linux, the only thing that I can say is that it took me quite some time to figure out how to set up my project correctly to get the SDK doing what it was supposed to do. The Digilent documentation is filled with errors.

 

[xc6lx45]

Hi,

just thinking aloud looking at the images in your July 4th post: Do you really need a 100 MSPS ADC? Or could it be possible that the dual on-board 1 MSPS 12 bit converter of the 7 series platform e.g. on a CMOD A7 (~$75) board is sufficient? Those are "relatively" (and I put that into double quotation marks) easy to use.

If yes, the design effort might be only a small fraction because so many problems from the more complex Eclypse system can be simply avoided.

[zygot]

The best tool for the job is a decent digital scope as @mor.paul isn't interested in becoming an FPGA or HDL developer... he just wants to complete his current assignment. Frankly, even though I love the challenge and doing HDL FPGA designs, I'd use a scope to get my measurements and move on to other things for a project like this. 

While the platform that you suggest is fine for experimentation it isn't in the same category as NIST certified test equipment nor is it, in general, a reasonable substitute for professional equipment.

Even if you have access to a wide selection of great readily available test equipment you still need to make sure that the specifications of the one** you choose is adequate for the job.

** In terms of an oscilloscope one really means system, including scope, probes, etc.