zygot
-
Posts
2,859 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Posts posted by zygot
-
-
1 hour ago, okonomiyonda said:
What I can't seem to find is any examples of the FPGA directly talking to DDR and UART.
Well you get points for doing some research. I suggest that you start with reading the Xilinx literature for the ZYNQ device on your board to see how the PS and PL connect. Then look at the schematic for your board to see what the various interfaces connect to. If you look on page 8 of the Arty 7 schematic you'll see that the DDR and UART signals are connected to PSxx pins or PS_MIOxx pins; that is to the PS. A few ZYNQ boards have DDR and or Ethernet connected to PL pins but most like the Arty7 have all of the user interfaces connected to the PS. SO... tying off the PS and just using the PL, something that is possible by the way, is going to be difficult for what you want to do. Neither the UART or DDR for the Arty 7 are connected to the PL. It is possible to create a program running as a bare-metal application to service an AXI connection between some design in your PL and the PS to allow you to connect a TTL USB cable to PL pins to a UART in your design. There are a number of options for building proper AXI interfaces to your PL HDL code and I like to use BRAM. Since your interface is a UART a DMA interface seems a bit extreme to me on face value... but I haven't tried to do this. My personal preference for ZYNQ designs is to have the bare minimal board design functions needed to connect the PS to the PL. I then use the HDL entity or module created by Vivado representing the board design as a component in my toplevel HDL design file where all of my real design goes.
I'm not quite understanding what exactly it is that you envision as the layers of hardware involved but you can't read/write directly to DDR from either the PS or the PL. Both have external memory controllers that are quite complicated, though on the PS side most of it might be something that you can ignore. Perhaps starting off with a simpler design concept; like creating a bare-metal PS application to read PL registers for address, write data etc and write other PL registers like read data. Given typical UART speeds a polled service should be usable. That project will be more than enough to keep you busy for a while.
I'm curious as to why you would want to do a ZYNQ project without the ZYNQ.
-
7 hours ago, moreabhinav said:
implement a scrambler on the zedboard
I assume that you mean that you implemented a scrambler in the PL.
If this is the case you need to add some IP provided by Vivado to allow the PS to pass data between the PS and the PL The PS will communicate with the PC uart using software and the PL logic will handle the communication between the PS and the PL using the interconnect There are a number of ways to do this. If you look in the IP Catalog you will see a variety of AXI and AXI-lite possibilities to allow your ARMs to pass data to and from the PL and your logic. You can't bypass the PS uart resource connected to the connector and send the signals to the PL directly. The easiest approach would be to use something like the AXI_GPIO IP, though you won't be connecting the signals to pins ( just logic ) The IP Catalog doesn't make finding all of the IP easy so keep expanding all of the categories until you find it. Once you export your hardware design to the SDK it will write a driver for you though you will still have to do some software development to create a complete application. There are a number of tutorials showing how to do this.
So the steps are:
- add the AXI peripheral interconnect IP of your choice to the board design schematic and generate the design
- build a new bitstream configuration file
- export the design to the SDK
- create an application that gets data from the uart and sends it to your PL scrambler then reads the output and sends the result back to the uart.
You will have to figure out a few details to make it all work but the tutorials should help with the basic concepts and using the tools. [edit] So I just realized that the previous steps are not quite right for you. I would have Vivado create an HDL to encompass the board design and then instantiate that into a toplevel design of my own that instantiates the scrambler. I think that what you are supposed to do is create your own scramble IP that you will integrate directly into the board design ( not use a standard AXI interface as I mentioned..) This is a bit more complicated than how I'd do it but there are tutorials on how to create and add IP to your own IP catalog.
To anyone else reading this thread for help in a similar project. This is a good example of why the Zynq isn't the best platform for all FPGA projects. You can do this project with a CMOD-A7 without the hassle and complexity of the board design and SDK. If this were a product the Zynq device would be too costly to be viable in the marketplace. As a project that makes you learn how to do the basic Zynq development flow it's a pretty good project. [edit] Personally, I find the whole IP creation thing to usually be too much trouble for the benefit, though I could see where I might want to do this. Sometimes it's good to learn how to do things that you never have to do...
-
I'm not sure that I understand your requirements either. As Jon mentioned the UART USB connector is tied to the PS. You can route PL pins to PS resources but your software will use the PS resources. For example you can connect PL pins to the unused uart resource in the PS and it will be used just like the one attached to the UART USB connector on the board. The SDK will even create a driver for it. Also, what you have then are 2 logic pins for Tx and Rx. You can use these internally in the PL with designs of your creation or externally but with additional hardware. If you want to connect this uart to a PC then assign the signals to a PMOD and attach those pins to a TTL USB UART cable or module that you buy separately. Adafruit and SparkFun both offer inexpensive versions. This approach would allow you to connect a PC to both uarts in the PS, both controlled by the ARM cores. The Zedboard PS has 2 Ethernet controllers and the same concept can be used to provide a second Ethernet port to the PS. In this case you will need to supply your own PHY using the FMC connector. What you can't do is mux the PS pins into the PL to, say create your own MAC-less (or custom MAC of your own design) Ethernet interface using the Ethernet RJ-45 connector already on the board.
It is certainly possible to use 2 PL pins connected to an HDL uart instantiated in the PL logic resources and send/receive data between it and the PS. In this case you will have to write your own drivers as the SDK doesn't have code to handle this. You will have to understand AXI bus interconnect IP.
Don't think of the Zynq as an FPGA with an embedded ARM core. Think of it as a big ARM uController with more resources than MIO pins but with a mux to allow routing signals to the PS to use resources that the board designers aren't using. The issue then becomes if the board designers offer IO connectors and routing that support doing that.
Let's say that you have logic in your PL to count pulses on PMOD pins and you need to reset the counts from the PS; you want to do this using the USB UART connector that comes with the board. You can certainly connect the output of your logic design to the PS through the AXI bus resources, directly as GPIO, or indirectly through BRAM or FIFOs. Perhaps this is closer to an answer to your question. If it is then you have some reading to do... There are tutorials about how to create custom IP and connect it to the PS... but I don't have links to them on hand.
-
Hi backatcha!,
I do appreciate the testimonial about your success with the Red Pitaya. Such comment help me assess my judgement about the suitability of unknown products. I've had enough unhappy experiences with investing time and effort into tools that restrict vital information that all I see are red flags when considering new ones. So now I'll have to revisit the product pages again in the future.
-
7 hours ago, Notarobot said:
Take a look at the Red Pitaya package
Oh that! I had such high hopes. This board started out as an open source hardware/software platform and now is something else. The hardware design is not available and calling the software open-source is probably a stretch. But the board is so close to being useful that I still check it out every few years as a possibility.... perhaps one day the company that controls this will go back to the project roots.
-
As far as a board with ADC and DAC devices meeting your sampling and bandwidth requirements look at Terasic ( they are Intel FPGA based ).
As to actual ADC and DAC devices meeting your delay requirements this is tricky ( you'll have to run through the data sheets for the devices on the Terasic boards if they look promising ). I don't know of any converter boards that I feel comfortable recommending that you can easily ( or with some difficulty ) connect to your FPGA platform. The ADC spec. game is challenging even for seasoned engineers. You probably want to look at flash or pipeline architecture ADCs. The current output DACs tend to have the least delay. Once you've figured out what components you want to use there's the analog end to consider. Usually ADCs need a good driver amplifier to get performance and if you use a current output DAC you will probably have to use an OP AMP to get a voltage of the desired span. These all will have a deleterious effect on delay on both ends. There is no easy answer for your question.
[edit] If you need to do any processing such as frequency filtering on the ADC or DAC sides this will also of course affect both data and group delay but you will have some control over this.
-
After mulling over my previous post here I thought that it might be good to post a few remarks about the IP in this project.
There's nothing specific to the CMOD-A735T in the code that makes up the IP, just that the dcp file was synthesized, placed and routed for that part. As my first offering of a project using Vivado I wanted to experiment with creating Vivado IP for distribution of functionality as opposed to source. I've since submitted a number of other projects to the Vault using the same IP but "compiled" for a different part. The basic functionality is part of a lot of my projects for internal use.
Having an HDL component ( really multiple components ) that converts std_logic_vectors to ascii hex and the other around is a very useful thing to have in your toolbox. Hopefully, you've looked though UART implementations in HDL ( even better taken the time to understand UART fundamentals and written your own UART ). If you have done that, you understand what a nifty thing it is to have is a UART based widget that allows for interacting with and debugging your FPGA design internals. Allowing a user to interact with this interface using a simple keyboard is, as I hope this demo shows, a very nice format for a number of reasons.
There are a lot of ways to solve design problems. Usually the most obvious is also the most complicated and the least elegant. The most elegant solution usually requires some insight that often requires quite a bit of experience. That's my segue into commenting on the std_logic_vector <--> ascii problem.
There's a number of ways to address this. A simple lookup table ROM is the most obvious; and happens to be the way the the IP in this demo does it. I also use a generate statement to create an array of processes to do this. I did it this way because I really had never tried using a generate process approach before, not because it was necessary or even efficient. ( For me being able to experiment with new approaches makes FPGA development interesting and fun ). Having said that, you should know that the user interface is totally customizable with respect to the size of the std_logic_vector and the approach that I took supported this easily.
If I was going to rewrite this portion of the IP again I likely would have taken a different approach. I also would have taken a different approach than use lookup tables. Can you think of alternatives?
The std_logic_vector <--> ascii portion of the IP is by no means the bulk of the design but perhaps the trickiest, especially for custom IP that uses generics to support any size std_logic_vector ( or, perhaps, unsigned ). There's nothing magical or innovative there. In fact, that's why I encourage whomever is reading this to work out their own solution. You don't need hardware... just ModelSim or Vivado simulator. That, to me, makes it an ideal problem for newbie HDL artists to solve.
I do want to end by mentioning that your can use the same IP provided in this demo in your own Artix 35T designs by studying how I use it here.
-
Hi @abd,
Part of the CMODA35T demo was indeed integrated into an IP form. The source for that code is not currently in a release form. The objective of the demo is to provide an alternate, quick and painless way for individuals new to the Xilinx toolset to create a bitstream and see their new CMOD-A35T working. Please understand that there aren't many people getting paid to provide code or assistance around here; so there's that pesky trade-off of providing something for free and providing something intended to better the "community".
The more important purpose of the demo is to encourage users to try developing their VHDL skills; so providing a bit of motivation to have them design their own functionality isn't a bad thing from my perspective. There is plenty of HDL source available in the Digilent Project Vault to assist in this process. Of course, there are also a number of people willing to help with specific questions on this forum as well.
I realise that developing you own code base ( IP if you will ) is a daunting task for those getting started and using the development methods that Xilinx and Digilent prefer appear to be an easier short cut to working designs. I'm encouraging the longer, more difficult, path because I believe that the destination is a much better place to operate in. There are other forums within the Digilent ecosystem that offer a discussion of ideas and might be interesting or even perhaps useful.
I do thank you for mentioning that you tried out the demo. I have been encouraged to submit new projects to the Vault and always try to allow users to expand on the project's limited objectives by re-using source.
-
It took a while to find out if anyone has tried out any of my posted projects... but thanks for the feedback. The project is as unambitious as one can get but does demonstrate an alternate to the standard Digilent demo and a lot easier to modify... plus it's relatively immune to Vivado versions.
This was one of the first projects that I did and it had specific goals. You might find the S3 Starter Board Programmer project interesting as well as it features the CMOD-A7-35T in a different role and has more HDL example code.
-
JColvin,
Sure, please do that. Tomorrow I'll be posting an esoteric but much more interesting project.
-
CmodA735tDemo is a Vivado project that requires very little resources and is an easy way to try out the board's resources.
Requires Vivado 2015.2 or later and a Cmod A7-35T board. There is a Python program to run the demo that also requires Python 2.7 and pyserial 2.7 but any terminal emulation program such as Putty will also work, though with a bit more effort.
NOTE: Vivado 2019.2 and later breaks the Vivado IP created in earlier versions. To build this project in Vivado 2019.2 just follow the README file except instead of adding the clk_wiz_0.xci file as IP you need to create an MMCM using the Vivado 2019.2 clock Wizard (use the default name) . The only thing that needs to be changed from the default settings is the input clock rate which is 12 MHz. I use the archive above from here to build the project just today using Vivado 2019.2 on WIN10.
UART Transmitter with BASYS 3
in FPGA
Posted · Edited by zygot
I suppose that the first part of this sentence is a pass for the second part but I still had to wince at reading it.
You can have storage using combinational (un-clocked) logic. If a synthesis tool decides that your code requires storage it will infer a latch; and provide a warning that it did so. The warning indicates that inferred latches are generally bad. One problem with learning your first HDL on your own from a book is that you might be tempted to use keywords without understanding the ramifications of your choices.
There is a place for variables and := in VHDL, but not for assigning values to logic elements like std_logic or std_logic_vector. A problem with offering a critique of code in a venue like the forum is that it's easy to provide advice that, while addressing an aspect of poor coding might cause more confusion than solution. There's only so much space and time for posting coding critiques and too often an attempt at making it concise and easy it ends up being misleading.
My point isn't to criticize hamster or anyone posting code; it's to suggest that there are better ways to learn how to use and HDL effectively than this format provides.