zygot
-
Posts
2,859 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Posts posted by zygot
-
-
Hi, It's been a while since you scheyduled a fix for the EclypseZ7 fan for bare-metal applications. Any progress to report? Last I checked the Digilent repositories are still being updated with no commentary as to what's changed and that's a big problem for users.
-
Final thought. Though reading FPGA vendor literature is a good idea before trying to design a project, if you are going to connect your FPGA IO pins to things it's a also a good idea to educate yourself on specific logic standards. You can pretend that FPGA development is just another kind of software development, at least in the beginning of your own development, as long as everything stays inside the device. Once you start connecting pins to other devices you are doing digital logic design and there's no pretending anymore.
-
1 hour ago, asmi said:
CC pins are only relevant for inputs AFAIK. Besides E15/E16 are actually CC pins
I stand corrected, and didn't take the time to look at the schematic. Thanks. On the plus side, now that I've been shamed into being a bit more responsible, and seeing the Arty A7 schematic, it does look like your choice of IO pins means that the standard habit of Digilent IO using 200 ohm series resistors isn't a concern.
I guess that I wasn't thinking that the fact that termination as a requirement for differential drivers isn't obvious. Think of them as similar to Open Collector (Drain) or ECL PECL. In my defense UG471 does say "requires external 50 ohm pull-up resistors". It mentions termination on the inputs but as @asmi has pointed out differential drivers don't do much unless connected to proper termination ( input or not ) as the termination completes the driver circuit. BTW, when the receiving end is powered by a different Vcc than the driver you can get into trouble if Vcc for both the driver and receiver aren't powered on simultaneously. This seems to be somewhat of a shortcoming for a video standard where monitors are usually different equipment than video source equipment, each with their own power supplies. Still, you can and should design your circuit for such eventualities. Driving current into your FPGA IO bank Vccio rails through IO pins isn't desirable at all.
Silly me, I thought that UG471 had a termination diagram for TMDS33... I seem to have gotten that wrong. Apologies.
-
1 hour ago, jamesW said:
Any idea what I am missing?
You can figure this out for yourself by going back to the first step of your project. This was reading the Series 7 Select IO User's Manual. Pay attention to the sections on TMDS33 IOSTANDARD, particularly study the termination diagrams. Then look at the schematic for your board and see if you can follow them.
Are you driving your sys_clk_p and sys_clk_n on clock capable pins? While you are getting the Select IO User's Manual take some time to brows through the Series 7 Clocking User's Manual.
-
-
9 hours ago, D@n said:
So ... I got to thinking, a virtual FIFO sounds like a really easy core to design--especially with an application like this one in mind.
What's better than an AXI Master Virtual FIFO for moving large quantities of data from an interface, like say 64 bits of 100 MHz ADC data , into DDR? No standard busses. Which is what I did for this project. It's just straight-forward HDL. There can be a case made for AXI, AMBA, Wishbone, or whatever but if I don't need any of the complexity of such a bus what good is it? Why would I want to worry about beats, bursts, boundaries, and a lot of other details if all they represent is unnecessary complexity and obstacles to achieving the best solution for my particular design problem? I wouldn't is the correct answer.
If my target platform was ZYNQ based, like the Eclypse-Z7, I might want to experiment with your virtual fifo master AXI design; but only if I could use it with the FPGA vendor's SDK tools to write the PS software end of the application. Since you don't know how to do that I'm having a hard time convincing myself that the reward is worth the effort for me to figure out how to do that. But I do respect that you worked out a good answer to one question on a three question test. What is that.. a C- on the curve? [whenever a prof gives a three question test in which you only get points for a completely correct answer you know that the purpose of the test is to convince most of the class to find another major]
But your post does suggest the need for revisiting a few issues of why ZYNQ isn't always the best platform for FPGA designs. The purpose of this project is to capture lots of data for post-event analysis. If the application was for an embedded self-sufficient device sitting on some mountain collecting and analyzing specific data I'd probably** want to use a ZYNQ device. For this project that certainly isn't the case. Though this was a 'proof-of-concept' project just to prove that it could be done, it turns out to be a pretty useful tool that can be used or modified easily for other projects. By the time you are waiting for Vivado to start up the SDK and update the workspace I can execute a single program on my PC that configures the FPGA and captures all fo the data, and save it to my HD. Well, not you since you don't use those tools.
So, it is possible to create a ZYNQ HW/SW application that uses the Ethernet port, as a user and data interface and can do a partial configuration of the PL to support one of a number of different PL specific applications, and execute it. If you want to run multiple of these applications simultaneously that becomes a harder problem to solve. If you want to make your life easy and use a lot of generic open source code to reduce your software design burden you will likely try using a Linux based OS. For something like the Eclypse-Z7 this is problematic for a number of reasons:
- Since you only have 1 DDR memory attached to the PS your AXI pipe(s) between the PL and the DDR has to compete with the PS for access.
- Your OS wants to use a significant about of the DDR leaving little for large quantities of data.
- running your fancy multi-core ARM code out of a relatively low speed SD card is problematic.
- Developing and maintaining ZYNQ HW/SW Linux applications is complicated and hard to do.
The first problem to resolve is finding the ZYNQ platform that is designed in a way that allows you to do what you want. This is certainly not impossible. Finding one that's affordable might be. Instead of thinking about AXI when you read this post you should be thinking " Hey using very little resources and using no embedded processor development at all with easily verified and maintainable HDL code can do some interesting things!"
Back to the Eclypse-Z7, assuming that this is the target. It doesn't matter how good your AXI virtual FIFO is, it isn't going to compete with my VHDL/Verilog Artix A75T implementation. And this was a lot easier to do, even with having to figure out a lot of Opal Kelly specific stuff. It's also a lot easier to use. If you absolutely need ARM cores and AXI then you have to put up with the extra hassle. Most of the time, for desktop or lab projects you don't.
[edit] ** Emphasis on probably because there would have to be compelling reasons to justify using an ARM based approach. I would certainly do a cost/benefit analysis first. ZYNQ is great for some applications that require an embedded processor with floating point hardware. It's an impediment for those that don't.
-
An update. I did manage to get the Eclypse-Z7 to put out 4 DAC channels. Again, I used the low level controller HDL provided by Digilent to jump start the design. Instead of using the Digilent AXI and SDK support code I re-purposed a previous Eclypse-Z7 test project using BRAM to communicate with my PL HDL. Instead of waveform lookup tables to drive the 4 DAC channels I used my own NCO IP. With the NCO I can get nice sinewaves from a few hertz to a few MHz by writing 1 32-bit word to the IP.
But, I got what I needed in about a day's worth of effort instead of wasting weeks trying to unravel the mystery that is the official Digilent ZMOD repository.
As anxious as I am to create a few interesting demos for the Eclypse-Z7 I'm hesitant because the product has such poor support. There is still no way to control the FPGA fan from a bare-metal application and the Linux support still can't do basic things like configure the PL and run an application....
-
Geez, I forgot that the baremetal DAC demo only drives one channel of a two channel DAC. It's not encouraging when a product vendor can't even figure out how to demo their own products satisfactorily... perhaps buying another DAC ZMOD isn't such as swell idea after all. There are easier ways to get the job done.... SIGH!
-
If I forget to set the ADC gain calibration to something other than 0 I remind myself of a really quick and fast way to initialize 1 GB of DDR to all zeros. Sometimes this is helpful and sometimes not so much...
-
40 minutes ago, D@n said:
Any special reason you aren't using a binary file?
Yeah, because I'm a salmon in a bathtub when it comes to writing software. Frankly, hopping back and forth between HDL and C doesn't seem to be getting easier with time.
I tend to like text based data files for debugging or development because for one, I can usually spot most things that are wrong in NotePad++, and two because I don't have to write a GUI application to render data into a visual format. With graphics application software I'm more of a toad in the toilet.... Of course when it becomes necessary I can put in the effort to do all of that if it becomes an important tool that I can reuse. Otherwise, I tend to make do with what I have readily available.
If this project was a full blown complete application I'd have to either format my data to be used with scope waveform viewers or write my own application to handle somewhat large datasets involving plotting, scrolling, zooming etc. Not today.
OCTAVE is pretty well written and current so it turns out that, while it might take 20 seconds to read in a 13 MB text file into memory, slicing the matrix and plotting manageable segments is both quick and a workable solution... for now.
-
I did figure out a way to scroll though 4M samples in a text file and plot 16K sample segments at a time using OCTAVE. Not pretty but usable. SCILAB is, unfortunately, just unable to handle matrices larger than about 64KB. No doubt an issue with how they handle memory.
I have a few things to clean up before getting moving on developing a ZMOD demo project that lets them be useful and avoid the dreaded storage closet where old and useless things sit hoping for a second chance...
-
38 minutes ago, D@n said:
If you just want to move from an AXI interface to a simpler interface, you can convert it to either AXI-lite or WB without too much hassle.
I think that our wires are crossed.
Except for some potential ZYNQ designs where it's unavoidable, I don't want to see or touch anything AXI. Even with ZYNQ I can usually step around them employing BRAMs or AXI FIFO streaming interfaces where I'm not worried about efficiency or data throughput. I don't see much use for all the hassle of incorporating an ARM into an FPGA design except for rare applications. For something like making a mid to high performance FPGA platform a ZYNQ solution is just going to get in the way. Now, it's possible to design a ZYNQ board that lets users do advanced IO designs. You just have to be willing to put enough PS DDR on the board to support it's OS and room for some large data buffers that might connect to the PL. You also have to provide the PL with its own DDR so support those advanced IO applications. Unfortunately, finding a moderately priced ZYNQ platform that does that is a rarity... off hand none come to mind.
Yes, I can see using a well designed AXI Master packaged in a way that's suitable for the Vivado flow so I can quickly build a standalone SDK application in the SDK or Vitas. Got one of those?
No I have no interest in experimenting with lots of 'bus adapter' IP that involves busses that I want to avoid like the plague.
Really I just want a nice non-ARM FPGA platform that doesn't prevent me from using all of that nice Series7 Select IO to its fullest capability.. and a 1gE or better yet 1,2.5,5,10 gigabit port, and a usable PCIe or USB 3.x platform/PC interconnect. The old Z7000 is really not ideal for a nice Linux/FPGA development platform. In theory the UltraScale ZYNQ families now have the processor horsepower to keep up with a Raspberry Pi 4 but the IO requires too much additional hardware to use the PL with most existing stuff that you might want to use it with. So you can get a cheap UltraScale board for less than a decent Z7020 board but you can't afford to connect it anything without a lot of expense and effort building you own adapter boards. I suppose that this is the price of technical advancement.
One point of this exercise is that using only HDL and even a low end plain old FPGA platform that has been reasonably well designed can do a lot more than a comparable ZYNQ platform with a lot less pain with a shorter design time using far fewer logic resources and be reusable in a different project using some future version of Vivado without spending weeks of resolving broken IP instantiations and code depreciation.
"I think I might disagree with you about CPU design being one potential or even necessary user of such a complex bus structure. It doesn't need to be so."
My reference here is to a standalone general purpose microcontroller IC that a customer might use on a PCB. Even then I'm not advocating for it, just possibly willing to concede that it might serve a useful purpose. I'd still rather have a simple external data pipe to deal with.
-
11 hours ago, D@n said:
was the virtual FIFO the only component that accessed memory?
If this was a ZYNQ platform and I was using the AXI Virtual FIFO I wouldn't be able to capture more than 4 channels of 32K samples each as there is a limit of 256KB with the core.
My philosophy is that pipes that just move data around should be as simple and fast as possible. The complexity should be in the logic. For ARM based FPGA devices the hard ARM complex is best suited to handle complexity that end. For the PL this is where your logic resources are. There's absolutely no design justification for putting AXI busses between the ARM complex and the PL. A simple bus with address, data and a handful of simple gating controls is ideal. Instead of 4-8 AXI pipes connecting the PS to the PL, and perhaps an application only using 1 or 2 of them, there should be one or two really wide fast pipes letting the user can decide how to best use them for their application. I mean customized application specific logic is the reason for being for an FPGA. It sure can't compete with non-programmable logic. Now if you are designing a ARM CPU without programmable logic I could see where you might want to expose complicated AXI or AMBA busses to the user who might want to hang a number of all sorts of peripherals with a combination of low speed low throughput and high speed high throughput. For an FPGA with an embedded hard ARM core complex this makes no sense to me.
-
An additional thought. It took me a lot less time to make use of the ZMODADC1410 for this application than it did trying to work out the overly complicated and poorly thought out Eclypse-Z7 supporting code... and I'm not close to being done with that as I write. Compare the two approaches. Compare the usability. with this platform I can write a PC application that configures the target FPGA, executes an application and quickly gets data to a PC for analysis or storage. The Eclypse-Z7 can't do any of that. At this point it can't do anything without an SDK or Vitas support.
[edit] I'm still hopeful that Digilent has the will to at least make the Eclypse-Z7 live up to its potential. It's flawed but still worth the investment in development time to allow users to do interesting things with.
-
Two ADC ZMODs each with a dual 14-bit (sign plus 13 bits) ADC. All four ADCs sampling at 100 MHz. This is an Artix 75T and is comparable to the PL in a XCZ020 device. No AXI anything. No processor cores. Just a couple of FIFOs, a DDR read/write controller, a Mig DDR soft controller, and some control logic. The ADC data is gain and offset calibrated so some of the bits can be thought of as fractional. But the DDR data write rate for 4 channels is 100 million 64-bit words/s. The DDR has a 32-bit data path. It sure would be nice if the Artix had a hard DDR controller like the Spartan6 it replaces as the Spartan6 DDR controller is both higher performance and more flexible. Unfortunately, the Mig is stuck with a 4:1 controller/DDR clock ratio, but it all works out. The DDR, for this application, is essentially a giant FIFO. A small state machine controls how many words are are captured and after capture the host application reads out the contents of the DDR. If you want to capture 128M samples per channel you could just write the DDR and use it as a circular buffer though this would complicate the design a bit. As I mentioned this is just a proof of concept design at the moment. This shows the possibilities for the boards involved. The SYZYGY is capable of demonstrating Series7 Select IO and each SYZYGY port could support a quad 16-bit ADC though the DDR would have to be beefier for 8 channels. Then there's the limitations of a small FPGA board and its power supplies. The FPGA never got above about 50C as measured with a infrared temperature sensor and has no heat sink. I'll probably add one at some point. The USB interface is vendor provided encrypt netlists and somewhat odd to work with but can do sustained 350+ MB/s data transfers befitting such a platform. The application was written in C++ using VS2019. As I mentioned I used as much vendor supplied code as possible to get off and running quickly. I had to do a few preliminary projects to create the Mig so the early ones were all Verilog. Once things came into place I copied the Mig and instantiate all of the Verilog into my VHDL toplevel entity. The USB interface allows for changing gain and offset calibration coefficients on the fly as well as analog front end gain and coupling options. It's all a lot cleaner and uses way less resources than AXI IP. Because the ADC data is aggregated into a 64-bit data word and written to an asymmetric FIFO (64-bit write, 1024 bit read) the application has to do some additional formatting to take 8-bit chars and create scaled real data in Volts. The ZMODs are nicely thought out and well implemented. A nod of appreciation to the design team responsible. Great job! It's really an adaption of the Analog Explorer ADC design beefed up for a higher performance platform.
The only Xilinx IP are the native MIg and FIFOs and an MMCM.
The thing that should impress people is the low resource utilization for the entire design. Try that with a Microblaze tricycle design approach! In the real world no one uses MicroBlaze because it takes up most of the resources and leaves the designer with little left to work with.
I'm still looking for that FPGA board that let's Series7 really shine. Take the Genesy2. Remove the FMC connector. Add 2-3 standard SYZYGY ports and a 4-lane SYZYGY transceiver port. Make the DDR with a 64-bit data path, keep the mDP as is, call it Genesys3 and now we're talking business**. TI makes some nifty Ultrasound AFE devices that could work with a double-wide standard pod arrangement. Actually, there's a lot of possibilities. As I pointed out earlier SYZYGY isn't necessary but is a nice format that allows for a wide range of FPGA design applications. For too long now students and experienced engineers on a budget have had to make do with hardware that doesn't allow them to make use of the resources of the FPGA devices they are paying for. That's more than a shame.
I could have done a similar 4 channel ADC design with the Cyclone V GT development board and two DDC HSMC mezzanine cards and used the PCIe 4-lane Gen2 as a PC interface though it would be messy since that board isn't really designed to sit in a PC properly. I have used a PCIe extender cable with that board. It's just nice to be able to do this with a Xilinx device and tools. The PCIe data rate is high enough to stream data directly into the PC memory.
** [edit] If you are going to make a nice platform like this it should have at least a USB3.0 interface for interaction with a PC and these days most boards that aren't the lowest end should have at least 1 high quality programmable clock module. Designing a good FPGA board is hard work. Why waste the effort by doing something half baked?
-
I suppose that now I have to buy another DAC ZMOD so that I can test 4 ADC channels. I have a lot more confidence in a 4 channel DAC with the Eclypse-Z7 as a useful combination.
-
Capture 4 channels of 120+ million ADC samples per channel. As a proof of concept project I just completed a design using the Opal Kelly XEM7320 with 2 Digilent ADC14010 ZMODs in a direct to DDR 4-channel ADC 100 MHz Fs application.
Opal Kelly has a unique approach to FPGA development that generally appeals to software developers. For me they do a few things that usually are show stoppers. For one most boards have a closed configuration/PC interface. The only way to use their boards is with pre-compiled encrypted netlists. For another they don't provide schematics, or even partial schematics. Their price point for hardware verses say Digilent or Terasic is substantially higher. Still, I've had success with their products which allows me to overlook the bad stuff.
It's great that Digilent has gotten into the SYZYGY game with two very good converter ZMODs. Not so great is their inability to make an FPGA platform product that showcases the potential for what amounts to as an opportunity to use Xilinx Series7 Select IO in all of it's glory. SYZYGY isn't the only way to go, though it is a worthy attempt at a plug and play cross-platform cross-vendor standard. Any board vendor can make an FPGA board that allow users to explore the full value of the Xilinx Series7 devices, they just have to want to and then design board that allows it. Don't let marketing people design boards, hire an experienced FPGA
guyperson and lethimthem design boards. Trust me it'll all work out in the end and everyone will be happy. You'll make money and you will have a broader customer base buying your stuff.The XEM7320 is the only non-ZYNQ board the Opal Kelly offers. It has an Artix 75T device and is priced competitively with the Eclypse-Z7. The XEM7320 has 2 standard ports and 1 transceiver port verses the Eclypse-Z7 2 standard plus 2 PMOD ports. The XEM7320 has a USB 3.0 PC interface and the tools for configuring the device from within the software application. The important feature that the XEM7320 has with respect to SYZYGY is a 1GB DDR device that ZMOD ADC samples can be written directly to.
I was able to bootstrap the Opal Kelly RamTester demo C++ and HDL code to make an application that can capture 128M 16-bit samples on 4 channels using 2 ADC1410 ZMODs. It's an all HDL mixed VHdl/Verilog design. No MicroBlaze. No board design. (almost) no vendor tool version issues. No SDK or Vitas, just VS2019, which is free these days. I used the Digilent ADC1410 low level controller code as a first cut though I will be replacing that with a more appropriate approach later. The DDR is essential just a very large FIFO.
The whole design resource useage:
LUTS <20%
LUTRAM 5%
FF 8%
BRAM <10%
DSP 2%
The VS2019 application configures the device and saves all data to an ascii file for use with SCILAB to OCTAVE.
The only big issue at this point is viewing large 4 column matrices in a waveform rendering. I'm open to suggestions. How is the best way to render a plot of this:
d = [
float4, float3, float2, float1, //sample 0
...
...
float4, float3, float2, float1] //sample 1048575
Thanks Digilent for bringing 100 Ms/s ADC/DAC options to the general Xilinx user audience. It's been a long time in coming.
[edit] Apologies to anyone reading the first version of this post where I got the sample count wrong. If I had a marketing guy writing this the title would have read " Capture over 1/2 Billion ADC samples". I hate it when the details deflate the high expectations of the attention grabbing headline, even if over half a billion samples is technically correct. I should point out that so far I've only capture and uploaded 1*1024*1024 sample for all four channels. The reason being that I don't have a way to verify more data than that. I did start of with a 100 MHz 64-bit counter written to DDR and that I was able to confirm. Even with a very fast USB 3.0 interface converting bits to mV and formatting even 10*1024*1204 samples and printing the data to a file takes more time than I want to spend at the moment.
[edit2] Gender and skill are not correlated at all. Don't select books or talent by the appearance of the cover.
-
4 hours ago, QuantAI-go said:
Nexys 4 seemed to be a good FPGA educational board. I thought that the Nexys video would give me enough capabilities to design small experimentation projects/applications in my areas of specialization.
So, for someone with no background in digital design or FPGA development the cheapest board will do. You don't have to think about external interfaces and advanced IO features. You will be concentrating on learning basic concepts and the tools. The tools are complex enough. There are a number of options under $150. The Arty A7 is a fine way to get started. Once you start getting a feel for how this FPGA stuff works and have started fleshing out the specifics of some of your eventual project goals then you'll know what peripheral interfaces are most important and will be in a position to make a better decision. I would encourage you to resist the idea of growing into a more expensive board that is designed to provide capabilities that you don't need. The Nexys Video is a fine board. I use one myself. As the name implies it's primarily for video applications though I use it mostly for other things. As for hidden costs you should be aware that Digilent doesn't really provide support for all of the features of all of its boards but relies on Xilinx IP and puts the burden on the user to figure out how to use them. The Nexys Video is a good example of this. Unfortunately, this is common among such vendors. It's a good idea to 'test drive' a board that you think that you are interested in to see what you are getting into. A good way to do this is to install Vivado and then download every demo provided by the board vendor and see if you can create a bitstream for it on your own. You will learn about required licenses and issues like tool version compatibility in short order. You can also see the level of support that you''ll get from the board vendor or the tools vendor. There's no scalability; if you need more external memory or FPGA resources or capability you need to buy a new board. Some boards so have a measure of extensibility like an FMC connector. The Nexys Video is one of them. Don't assume that you will find an FMC mezzanine card with the features you want and expect it to work with a particular FPGA carrier board though.
I've done plenty of DSP design work in VHDL using devices less capable than a Artix 35T which is near the low end of Digilent's portfolio. You don't need to use vendor IP either.
I highly encourage you to adopt the Verilog or VHDL design flow even though, up front, the board design flow using vendor IP seems easy. This is especially true for Ethernet; particularly if you want to do something unusual with it.
As for ZYNQ I'd advise this as an unnecessary complexity and distraction for people learning an HDL flow. Understand how to design logic and verify it first. When you have designed your experiment and can partition some elements as being processor efficient verses other elements being logic efficient then you can decide if this is appropriate. Don't get distracted by non-essential frills, especially before you get your 'sea legs'.
I would suggest that you stick to boards with a 14-pin JTAG header for a number of reasons.
[edit] You mention machine learning. Intel is big into this. Terasic has a few inexpensive OpenVino boards for this. The GT version of the C5P is designed to be an machine learning 'accelerator' , though on the low end. I use one myself for other applications. You can use the free tools for this board. Xilinx doesn't have anything comparable to this at an affordable price. At least look around. Both Intel and Xilinx are big into this arena but only for the well heeled. You need to do a lot of homework to figure out where the gotcha are though. in general, the more layers of tools there are the more nasty surprises are waiting for the uninformed.
-
1 hour ago, xc6lx45 said:
Digilent will probably have something similar if you search a little.
Just when I was about to complement @xc6lx45on posting a more succinct reply by focusing on the most glaring problem with your question he interrupts my train-wreck of thought with a second post.
A sure way of de-railing ( notice how I can keep to a theme? ) a project is to under-estimate the requirements or complexity involved. If you anticipate that learning how to do useful FPGA development is a trivial step toward completing an FPGA-centric application then you are in for some unpleasant surprises. I've know people who were brilliant enough to seemingly side-step all of the preliminary preparatory work and experience that mere mortals like myself would need in order to accomplish something remarkable but this is truly a rare individual. Even if you know everything that need to be known about the topics and theory of a project there's another couple of levels of complexity involved with tools, IP, licensing etc to trip you up. Lot's and lots of levels of details waiting to complicate your intentions.
Possibly the best question for @QuantAI-goto deal with is: "Why do you believe that an FPGA is necessary or even appropriate for your particular efforts?"
For anyone other than the original questioner reading this I need to make a comment about FPGA vendors. I've used the tools of every FPGA vendor out there and a few who've gone the way of the Moa. Anyone out there remember WARP? It's not unusual for me to be doing a project involving both Intel and Xilinx tools and devices and involve more than one board with an FPGA on it. Assuming that you are already competent in an HDL you have to be very careful about hidden costs and issues that might force a rethinking about how you might implement a particular interface. Intel is especially scrouge-like in terms of allowing potential customers to evaluate a part for a project. You can't create a bitstream for all Cyclone devices these days without purchasing a 1-year license for the tools. Want to use a Cyclone10 LP? Fine, you can use the free tools. Want transceivers or something akin to older Cyclone parts like Cyclone V? Too bad you need to buy license for a version of Quartus that only lets you create a bitstream for the Cyclone10 GX devices. Want to try out a higher end part? Too bad, you need to buy a license for yet another version of Quartus that lets you target any device, except of course those Cyclone10 GX parts. Think that a Quartus license is cheap? Go find out. In my experience some projects can be easily done using Intel devices and their supporting hardware ecosystem but might be way too expensive for other projects. There's much less overlap between what you can do, in a limited budget, between the Intel universe and Xilinx universe than you might hope for. It's mostly due to different marketing strategies. Both companies use a heavy hand in controlling their ecosystems and the low end ( in terms of revenue ) get serviced. Do your homework and choose wisely before spending money.
-
You're in Luck! Here at Quick-draw Bill's University of Cosmetology, Neuro-Surgical, and Electrical Engineering Arts we equip people for the multi-dimensional skills required by tomorrow's workplace. Sorry... just kidding... haven't finished my morning cup of coffee.
So while I can wrap my head around what most of the things you mention might entail I'm still having difficulty figuring out how all them are connected. Fortunately, I'm awake enough to figure out where to start the interrogation. You didn't think that you could come here and get help without an interrogation did you?
To me the obvious place to start is by side-stepping the complicated questions and getting straight to business. Why did you decide that a Nexys Video is the ideal board for completing your project portfolio? Is there a lot of video involved? If so I'd recommend spending the extra money on a Genesis2 as the FPGA is much more capable. But really that question is intended only to get you focused on a basic issue. Let's put aside what the FPGA device requirements might be since there's no detail on which to make such an assessment. You obviously want the most performance that you can afford in terms of selecting an FPGA device and will have to settle for designing an application that fits its capabilities. Evidently, you've already determined that and Artix 200T is sufficient for your needs. Perhaps telling us how you made that determination might help you get a helpful answer.
As for selecting an FPGA board platform for learning FPGA development or some generic Verilog or VHDL experimentation this is a bit more solvable. First, you need to decide what features your platform requires. Does it need external memory? Does it need Ethernet connectivity? Does it need to be extensible (work with specific add-on boards)? Clearly, you want Ethernet connectivity. I know a little about what's involved in high-speed, low latency trading applications and I can tell you that they don't involve a MicroBlaze and proprietary MAC IP. There are no FPGA boards available for you to buy that are suitable for this actual application. That doesn't mean that you can't do 'deep packet inspection' and try and emulate 'low latency' whatever that means for your demonstration project. It does mean that you should be doing everything in an HDL, that you code by yourself. This implies that you have a very good understanding about all of the layers that make up Ethernet. You should know that what you can do in a particular FPGA device using only logic narrowly crafted for a particular purpose in VHDL or Verilog is very different than what you can do using vendor provided IP with a MicroBlaze. This design flow will use up significant resources of your FPGA device that you might need for actual working logic. In fact, MicroBlaze and low latency are headed in opposite directions.
You ask: "what would be the best data/peripheral connection options to achieve high throughput and low latency on this board? Is it possible to extend the board with PCIe?". This implies that moving data between your FPGA platform and a PC is a critical specification. Notice that I left of the part about 'for this board' because I don't think that you're ready to make that call yet. A board with a 1Ge port, DDR memory, PCIe and HSMC connectors for extensibility could be the Cyclone V GT Devlopment board. There is even a possibility for developing applications using that PCIe and I'm betting that you are fairly clueless as to what that entails. That wasn't an insult. That means that there are a lot of things that you need to understand before you decide that an interface is what you want to use. Of course nobody doing high-speed trading is thinking about 1Ge Ethernet except possibly as a debug port, so perhaps 10/100 is adequate for your project demonstration.
2 hours ago, QuantAI-go said:full computational capacity of the Artix-7 XC7A200T
You'll need to explain yourself a bit clearer here because your choice of words is telling me that you aren't quite grasping what it is that an FPGA does. This is a big problem. You don;t want to start designing your projects to work on a platform that doesn't support its requirements.
Rule 1 of selecting an FPGA development platform: Don't choose a board that you hope will meet your needs. Figure out what your project requires and choose a board that supports it. This implies that the first step is defining a project. Specifying the project requirements in terms of hardware. Lastly, looking around for the best fit within your budget.
-
3 hours ago, malexander said:
hopeful that it will be sometime in early May.
Thanks, the information is appreciated.
-
@malexanderIs anyone closer to making the Eclypse-Z7 fan control available to non-Linux application code? Is there any plan to provide a Standalone source for accessing the PMCU registers from the ZYNQ? The protocol isn't supported by Xilinx PS example code as far as I can tell.
It would be nice if developers would update the Digilent GIT repository with status commentary so that users would be able to know when changes worthy of going to the trouble of updating the source is appropriate.
-
Thanks, The FAN isn't a fire yet ( as far as I know ) so I don't need a solution today, but I'll certainly need to turn it on and off at some point.
The people who argued that an Eclypse-Z7 Linux OS is a normal use case didn't seem to get the hardware people on board and have a lot of work to do to make that a reality. As of now its only purpose seems to be to connect the Ethernet port to the SDK for running Linux applications from the SDK.
For what it's worth, I'd argue for not having a live FS, so that no one can destroy the FS accidently. There should be space available in the FLASH to store inter-session configurations, setting and what have you.
-
Ok, that's something.
Currently, I'm doing development for bare-metal applications so I'm not booting into the FS, just booting into JTAG mode. So, how do I control the FPGA fan when there's no OS to run decutil or any other application/utility?
On the subject of permissions; it a real hassle having to do 'sudo systemctl poweroff' and then have to type in a password just to shut down the OS before hitting the power off switch.
I can only imagine the debates that went on while developing this product; and am happy not to have been involved. Still, the result is an OS that doesn't seem to know what it exists for, at least on running development code, and a board that can, in theory, support bare-metal, Xilinx RTOS, or other configurations. As of today, I find the Eclypse OS as more of a distraction than a platform for developing applications. Lot's of disconnected appendages in the Eclypse-Z7 ecosystem.
You don't have to work to hard to confuse me but I have a distinct feeling that I'm not alone here.
Regardless, of application I need to be able to run the FAN.
P.S. Juggling various Linux, Xilinx and other platforms while working on multiple projects might be fun for software guys but it really is a headache for poor old me. Debian might be mother, but her offspring certainly don;t play well together. Let's see, is it ifconfig, no wait what am I running at the moment? ARRRRG!!!
Eclypse-Z7 FPGA Fan
in FPGA
Posted
Thank you Michael.