Leaderboard


Popular Content

Showing content with the highest reputation since 03/04/19 in all areas

  1. 2 points
    Hi @Blake, I was struggling with the same problem. In Adam's project is mistake which result is an FMC-HDMI module is not recognizable by other devices. The reason for that is not sending EDID at all. The cause of this situation is wrong initialized EDID map. In Adams example EDID is initialized by: but the correct way is: the body of iic_write2 is from LK example: By the way, in LucasKandle example initialization is done in same way as in Adam's example so is the reason why it not worked in your case. I hope it will helps. If you want I will post my working code for a ZedBoard with FMC-HDMI when I clean it because at the moment is kind of messy.
  2. 2 points
    kwilber

    Pmod DA3 clocking

    It seems to me the AXI Quad SPI block is sending address + data. Looking at the .xci file again, I see C_SPI_MEM_ADDR_BITS set to 24 bits. So 24 bits of address and 16 bits of data would yield 40 bits.
  3. 1 point
    Hi @m72 After adding the Order option in Logic Analyzer (splitting the Input selection in two) I have forgotten to update the Protocol/Logic Analyzer to set the Order option automatically. Thank you for the observation, it is fixed for the next release.
  4. 1 point
    zygot

    Using tera term for two pmods

    Well I think that this is better stated as saying that most serial terminal applications can only connect to one COM port at a time. It is possible to mave multiple UARTs in your FPGA design and connect to multiple serial terminal applications. I like Putty myself, but there are other options. Another possibility is to look around in the Digilent Project Vault and see at least 3 project with source code that might accomplish what you want to do. If you instantiate your own UART you can access any number of internal registers or memory.
  5. 1 point
    Hi @Lesiastas You should use higher sample rate to capture raw data than the UART rate. Otherwise due to clock jitter and signal slew rate the capture could be wrong. Imagine on sample could be captured exactly on bit start and next bit on the end of the same bit, instead of next bit start... Anyway, here I have modified the decodeUart to work with sample rate = uart rate, see the lines marked with ' ' ' ' Module Module1 Function decodeUart(ByRef rgData() As UShort, ByVal cSamplePerBit As Integer, ByVal pin As Integer) As List(Of Byte) Dim pData As Boolean Dim fData As Boolean = False Dim cSamples = rgData.Length Dim rgUart As New List(Of Byte) For i As Integer = 0 To cSamples - 1 Dim s = rgData(i) pData = fData fData = 1 And (s >> pin) If pData <> 0 And fData = 0 Then Dim bValue As Integer = 0 For b = 0 To 7 Dim ii = Math.Round(i + (1.499 + b) * cSamplePerBit) ''''' If ii >= cSamples Then Exit For End If s = rgData(ii) fData = 1 And (s >> pin) If fData Then bValue += (1 << b) End If Next rgUart.Add(bValue) i += cSamplePerBit * 9.499 - 1 ''''' 1 start + 8 bits + 0.5 stop -1 because For will increment End If Next Return rgUart End Function Sub Main() Dim hdwf As Long If FDwfDeviceOpen(-1, hdwf) = False Then Dim szError As String FDwfGetLastErrorMsg(szError) System.Console.WriteLine("Device open failed" & vbCrLf & szError, vbExclamation + vbOKOnly) End End If Const hzUart = 9600 Const hzRate = hzUart * 3 ''''' Const cSamples = 1000 Dim hzDI As Double FDwfDigitalInInternalClockInfo(hdwf, hzDI) FDwfDigitalInTriggerSourceSet(hdwf, trigsrcDetectorDigitalIn) FDwfDigitalInTriggerSet(hdwf, 0, 0, 0, &HFFFF) 'any falling edge 'FDwfDigitalInTriggerAutoTimeoutSet(hdwf, 10.0) FDwfDigitalInDividerSet(hdwf, hzDI / hzRate) FDwfDigitalInSampleFormatSet(hdwf, 16) FDwfDigitalInBufferSizeSet(hdwf, cSamples) FDwfDigitalInTriggerPositionSet(hdwf, cSamples - 10) FDwfDigitalInConfigure(hdwf, 1, 1) Dim sts As Byte While True If FDwfDigitalInStatus(hdwf, 1, sts) = 0 Then Return End If If sts = DwfStateDone Then Exit While End If End While FDwfDigitalInDividerGet(hdwf, hzRate) ' get the actual rate Const cSamplePerBit = hzRate / hzUart Dim rgData(cSamples) As UInt16 FDwfDigitalInStatusDataUShort(hdwf, rgData, 2 * rgData.Length) Call FDwfDeviceCloseAll() Dim rg0 = decodeUart(rgData, cSamplePerBit, 0) System.Console.Write("Hex 0: ") For i = 0 To rg0.Count - 1 System.Console.Write(" 0x" + Conversion.Hex(rg0(i))) Next System.Console.WriteLine() System.Console.WriteLine("Text 0: " + System.Text.Encoding.ASCII.GetString(rg0.ToArray)) End Sub End Module
  6. 1 point
    Cristian.Fatu

    tera term for two pmods

    Hello, The PmodAD2 communicates over I2C protocol with the main board on which the Pmod is plugged. The PmodAD2 has no UART / USB capabilities. It is the main board that communicates - using its USB-UART capability - with the PC. Connecting the board using a USB cable creates a COM port on the PC. When you open a TeraTerm (or other terminal) connection, you select the COM port. Therefore a possible approach could be to have 2 PmodAD2 connected to a single main board, in different Pmod connectors. The SDK application should gather the AD2 data (measurements), format a text message containing these measurements, and then sending the text message over UART to the PC, to be later visualized in a terminal. What application are you running on the FPGA board ? You should modify it to read the other Pmod as well.
  7. 1 point
    Hi @m72 The preview is further fixed. I hope there are no more issues with this: https://forum.digilentinc.com/topic/8908-waveforms-beta-download/ Here you have the project: EMU_2CH_EACH_V10 (2).dwf3work
  8. 1 point
    Hi @m72 The pulse preview is not correct. I will look into this. Thank you for the observations. You could use a custom bus or signals to easily create/modify such patterns.
  9. 1 point
    Actually, I'm not sure what Diglent's policy is about questions that aren't specific to Xilinx or Digilent products. The various FPGA vendors are certainly competitors but I have a hard time seeing non-commercial customers as 'competitors' regardless of which vendors' products they are using. I would agree that, even though some of the people who respond to questions posted to Digilent's Forum have recent experience with a variety of FPGA vendor's devices and tools, posting questions to a website dedicated to Xilinx based products when your question is specific to Intel is a good way to get bad information and probably unwise. Also, and this hasn't happened yet, I suspect that having a lot of questions about non-Xilinx devices and tools would be confusing to a lot of readers and make the experience for many of them of reading posts to Digilent's forum less useful. Intel has a community forum as does Xilinx. Neither is, in my experience, as helpful as Digilent's most of the time. Intel is, well not Altera, and even Altera's community support wasn't that great. Digilent's Forum is a great place to ask about Digilent products and Xilinx tools. Even restricted to that it' must be hard for people to find answers that have already been posted because a a lot of questions keep getting repeated. I do heartily suggest that it would be more appropriate to seek out answers to questions like saif1's at forums where people who hang out there are very knowledgeable about the tools and devices for the platform that you are working on. There also must be vendor agnostic forums out there somewhere dealing with FPGA development tools and devices. My last word is that an awful lot of questions would be answered if the poster only took the time to read through the vendors' literature. If there's any practice that's bad form it's wasting other peoples time because you can't be bothered or don't have the time to read readily available literature. Everyone's time is as important to them as yours is to you.
  10. 1 point
    Tim S.

    Pmod OLEDrgb with Zybo Z7

    Just to make sure my explanation is thorough. The above has a typo. It should read: Linux has a case-sensitive file system whereas Windows has a case-insensitive file system.
  11. 1 point
    D@n

    Custom IP

    @PoojaN, You're not the first person who has asked this. If you just want to blink an LED, then I'd recommend a different approach that avoids all the pain with AXI in the first place. (You don't need AXI ...) If you want to start interacting with AXI cores, then you'll need to learn AXI. Sadly, this isn't as simple as it sounds. Xilinx picked the AXI bus to connect all their components with. This may have something to do with their ARM integration, since if I understand correctly AXI is an ARM creation AXI is not a simple bus to work with. Unlike Wishbone, it has five channels associated with it each of which can stall. These are the read address channel, the write address channel, the write data channel, the read response channel and the write response channel. One bus failure, and your device will lock up. In my experience, using an ARM+FPGA chip, lockups could only be fixed by cycling the power leaving you ever wondering what had caused the problem. Part of the problem is that the AXI standard has no way of recovering following a dropped response other than a total system reset. As I've implemented Wishbone, you can just adjust one wire (the cycle line--but that's another story) and start over. You can even use a timeout to clear the bus if a peripheral has not responded within an expected period of time. Not so with AXI. AXI is so difficult to work with that not even Xilinx could get it right. (See the links above) When I first discovered these bugs, I wondered that no one had found them before. For example, two writes in a row would lose a response and lock up the bus if ever there was the slightest amount of backpressure on the return channel. (Something Wishbone doesn't have to deal with, since there's no way to stall a Wishbone acknowledgement) It would seem as though very few individuals ever simulated their cores with backpressure (i.e. either BREADY or RREADY signals low), and so they never noticed these bugs. Similarly, some configurations of the interconnect might trigger the bugs while others wouldn't. Imagine adjusting the glue that holds your design together only to find your design starts failing. What would you blame? The interconnect, right? When in fact it was their demonstration core logic at fault that everyone was copying. I've now fielded several questions in the last several months alone on Xilinx's forums from users who've struggled with these bugs. If you do searches, you'll discover that folks have been struggling with these sorts of problems ever since Xilinx started using AXI. In one recent post, a software engineer posted that his FPGA engineer had left, leaving them with a "working" design. He then adjusted the software within the design and the whole design now froze any time he tried to write to their special IP core twice in succession. I'm hoping Xilinx will fix these bugs (soon). I haven't checked their latest release since reporting them, but I do expect them to fix the bugs in the near future. It's not just Xilinx either. I'm currently verifying the (ASIC) soft core of a major (unnamed) vendor. Much to my surprise, despite a team of highly paid professional engineers working to produce this amazingly complex core , and despite the fact that they created a simplified subset of the AXI interface standard to work with ... they still didn't get the AXI interface right. Realizing how difficult this was, I tried to simplify the task by creating a couple of cores. One showing how to build a bug-free AXI-lite slave (link above), another showing how to build a bug-free AXI slave (link above again). I also shared an AXI bridge implementation that, if you place your core downstream of it, you'd be guaranteed to meet the AXI protocol--even if it slowed you down a touch. I also shared the code for verifying that an AXI-lite component works--you are free to try it out yourself to know if your core still works after changing it. If you like using Wishbone, I've posted an AXI-lite to Wishbone bridge, or even a Wishbone to AXI bridge in case you want to access your DRAM memory. I also think you'll find that all of these cores, save perhaps the bus fault isolator core, will have better performance than Xilinx's logic ever had. Whether or not you use these options (or give up on AXI as I've tried to do) ... well, that's up to you. Forget what the sales brochures tell you, we aren't playing with legos here. There's more required to hook things together then just plugging them into each other--especially if you want something that works reliably when you are done. Just want something simple? Learn Verilog or VHDL. At least then you'll be the one responsible for your own bugs. Dan
  12. 1 point
    You can find newer version 1.0.0.76 in the description of the video: https://www.youtube.com/watch?v=4d3hc-9zBaI
  13. 1 point
    yes, for an application with basic requirements, like receiver gain control this will probably work just fine (it's equivalent to an analog envelope detector). Now it needs a fairly high bandwidth margin between the modulation and the carrier, and that may make it problematic in more sophisticated DSP applications (say "polar" signal processing when I try to reconstruct the signal from the envelope) where the tolerable noise level is orders of magnitude lower.
  14. 1 point
    Hi @Ahmed Alfadhel I had the C code handy because I have been working on an atan2(y,x) implementation for FPGAs, and had been testing ideas. I left it in C because I don't really know your requirements, but I wanted to give you a working algorithm, complete with proof that it does work, and so you can tinker with it, see how it works, and make use of it. Oh, and I must admit that it was also because I am also lazy 😀 But seriously: - I don't know if you use VHDL or Verilog, or some HLS tool - I don't know if your inputs are 4 bits or 40 bits long, - I don''t know if you need the answer to be within 10% or 0.0001% - I don't know if it has to run at 40Mhz or 400Mhz - I don't know if you have 1000s of cycles to process each sample, or just one. - I don't even know if you need the algorithm at all! But it has been written to be trivially converted to any HDL as it only uses bit shifts and addition/subtraction. But maybe more importantly you can then use it during any subsequent debugging to verify that you correctly implemented it. For an example of how trivial it is to convert to HDL: if(x > 0) { x += -ty/8; y += tx/8;} else { x += ty/8; y += -tx/8;} could be implemented as IF x(x'high) = '0' THEN x := x - resize(y(y'high downto 3), y'length); y := y + resize(x(x'high downto 3), x'length); ELSE x := x + resize(y(y'high downto 3), y'length); y := y - resize(x(x'high downto 3), x'length); END IF My suggestion is that should you choose to use it, compile the C program, making the main() function a sort of test bench, and then work out exactly what you need to implement in your HDL., You will then spend very little time writing, debugging and improving the HDL because you will have a very clear idea of what you are implementing.
  15. 1 point
    Hi @pikeaero, Welcome to the Digilent forums! best regards, Jon
  16. 1 point
    Hi, I just have opened a new terminal and launch minicom through the new terminal which works the same way as SDK terminal but I have to close the SDK terminal before connecting to minicom. Thanks @D@n and @jpeyron
  17. 1 point
    attila

    Scope custom math channel limitations?

    Hi @P. Fiery You could use the View/Logging/Script to create an up-sampled reference channel like this: var rg = [] var v2 = 0 Scope.Channel1.data.forEach(function(v1){ rg.push((v1+v2)/2) rg.push(v1) v2 = v1 }) // upsampling by 2 doubles the sample rate Scope.Ref1.setData(rg, 2*Scope.Time.Rate.value)
  18. 1 point
    jpeyron

    Pmod da3 reconstruction filter

    Hi @lwew96, We have not used a reconstruction filter. I did find a paper that discusses a reconstruction filter with the AD5541 here. Hopefully one of the more experienced community members will have some input for you as well. best regards, Jon
  19. 1 point
    Hi @kuc3, Welcome to the Digilent Forums! I have moved your thread to a sub-section where more experienced embedded linux engineers look. best regards, Jon
  20. 1 point
    Hi @dmishins, Welcome to the Digilent Forums! Please attach a screen shot of your Block design. Did you connect the 200 MHz clock to the MIG as instructed in section 10? What did you set the local memory and cache when running clock automation for Microblaze? best regards, Jon
  21. 1 point
    D@n

    Noisy Output from FIR Compiler

    @Ahmed Alfadhel, You have a couple of options available to you: It's not clear, from your pictures above, whether or not the -40dB stop band was achieved. Some amount of noise is to be expected due to truncation errors, etc. Without seeing an estimated PSD, I can't tell. It may be that it's doing exactly what you required of it. -40dB is only so good. With more taps, you should be able to go deeper. How deep depends upon your requirements. How good do you want the signal to look? You may also need to provide more bits to both your signal and coefficient values in order to do better. You did prescale your coefficients so that, when rounded to integers, the taps were useful, right? Also, be aware, the filter will be specified for full scale. You'll want to measure it against a full scale input. Anything less will introduce additional truncation error. This is one of those reasons why the dynamic range (i.e. number of bits) of the input and output signals are so important. Enjoy! Dan
  22. 1 point
    Hi, For sw part I use Xilinx DMA driver (interface to VDMA IP core) and modified ADI AXI HDMI DRM driver for exposing frame buffer device to GUI sw (e.g. Qt). You can see driver bindings in above attached zyboz7-20.devicetree-1.zip (pl.dtsi). All video memory transfers to FPGA are managed by this two drivers.
  23. 1 point
    Hi @ahmedengr.bilal, Like I mentioned in the previous post there is no HDMI output from the Linux side, neither the embedded rootFS provided by petalinux nor the kernel configuration we give out is set to accommodate this feature. Regarding the missing media-ctl and v4l2-ctl, you have not activated the v4l-utils in the rootfs configuration of the petalinux. to do this you need to navigate to your petalinux project folder and run: petalinux-config -c rootfs Once the menu appears you need to go to Filesystem Packages->misc->v4l-utils and activate: v4l-utils, libv4l, media-ctl. Rebuild the whole project and it should be working now. -Ciprian
  24. 1 point
    jpeyron

    ZedBoard and PmodCAN

    Hi @YellowYoung, Welcome to the Digilent forums! The PmodCAN facilitates CAN communication to another device through the PL.The PmodCAN uses SPI communication to communicate between the host board and itself. It would not be able to connect to the CAN on the PS. To use the CAN bus on the PS you would need to use the MIO Pmod JE1 as discussed in the user guide for the Zedboard here in section 2.9.2 Digilent Pmod Compatible Headers (2x6). The user guide states the bank that the MIO pins are connected to a 3.3V bank so you would need to make a level shifting circuit for CAN communication to work since CAN uses voltage level as part of its communication. If all you need to do is communicate data from the Zedboard using CAN communication. Then you can send data from the PS to the PL and then send that data through the PmodCAN. Here is an Avnet forum thread that discusses sending data from the PS to the PL. Here is a Xilinx forum thread that initially discusses how they accomplished sending data from the PS to the PL. best regards, Jon
  25. 1 point
    xc6lx45

    FIR compiler Amplitude

    My first guess is that the tool needs to know the position of the decimal point of your number format. It's off by 20 bits (=> 1048576 => 120 dB). Fixed point knows only integers, so it's a matter of interpretation.
  26. 1 point
    Yep, seen that they were back online. Thanks, Jon
  27. 1 point
    jomoengineer

    Howdy from NorCal

    Thanks Jon. And thanks for the links. Cheers, Jon
  28. 1 point
    The example I posted would work for Linux or Mac with "common" tools installed. As to Windows... can't really help much there. git's not part of Python, it's used for managing code; you can achieve the same end result here by downloading the ZIP from https://github.com/bdlow/dlog-utils-portable/archive/master.zip and unzipping to a folder. Virtual environment support is a standard part of Python 3; you can skip that if you like but without virtual environments eventually your Python installation will end up like this: https://xkcd.com/1987/ Ah, of course, in Windows `activate` is a batch script not a shell script: https://www.techcoil.com/blog/how-to-create-a-python-3-virtual-environment-in-windows-10/
  29. 1 point
    attila

    Logic Analyzer Counter Function

    Hi @Lars Lindner You can perform a recording and see the pulses using quick measurements or measurements like this:
  30. 1 point
    jpeyron

    hdmi ip clocking error

    Hi @askhunter, I did a little more searching and found a forum thread here where the customer is having a similar issue. A community member also posted a pass through zynq project that should be useful for your project. best regards, Jon
  31. 1 point
    For the Protocol / SPI-I2C /Spy mode you should specify the approximate (or highest) protocol frequency which will be used to filter transient glitches, like ringing on clock signal transition. The Errors you get indicate the signals are not correctly captured. - make sure to have proper grounding between the devices/circuits - use twisted wires (signal/ground) to reduce EMI - use logic analyzer and/or scope to verify the captured data / voltage levels at higher sample rate at least 10x the protocol frequency Like here in the Logic Analyzer you can see a case when the samples are noisy:
  32. 1 point
    @longboard, Yeah, that's really confusing isn't it? At issue is the fact that many of these chips are specified in Mega BITS not BYTES. So the 1Gib is mean to refer to a one gigabit memory, which is also a 128 megabyte memory. That's what the parentheses are trying to tell you. Where this becomes a real problem is that I've always learned that a MiB is a reference to a million bytes, 10^6 bytes, rather than a mega byte, or 2^20 bytes. The proper acronyms, IMHO, should be Gb, GB, Mb, and MB rather than GiB or MiB which are entirely misleading. As for the memory, listed as 16 Meg x 8 x 8, that's a reference to 8-banks of 16-mega words or memory, where each word is 8-bits wide. In other words, the memory has 16MB*8 or 128MB of storage. You could alternatively say it had 1Gb of memory, which would be the same thing, but this is often confused with 1GB of memory--hence the desire for the parentheses again. Dan
  33. 1 point
    Hi @Phil_D The gain switch is adjusted automatically based on the selected scope range. At 500mV/div (5Vpk2pk ~0.3mV resolution) or lower the high gain is used with and above this the low gain (50Vpk2pk w ~3mV resolution). In case you specify trigger level out of the screen (5Vpk2pk) or offset higher/lower than +/- 2.5V the low gain will be used for the trigger source channel. This will be noted on the screen with red warning text. The attenuation is a different thing. This option lets you specify the external attenuation or amplification on the signals which enter the scope inputs and the data is scaled accordingly. Like, if you use a 10x scope probe, the scope input will actually get 1/10th of the original signal, but specifying 10x attenuation the signal is scaled to show values on the probe. In this case the 500mV/div (5Vpk2pk) low/high gain limit moves up to 5V/div (50Vpk2pk) and the low gain up to 50V/div If you have an external 100x amplifier on the scope input you can specify 0.01x attenuation. With this you will have 5mV/div (50mVpk2pk ~0.003mV resolution) for high gain.
  34. 1 point
    HI xc6lx45: Well, to my surprise, when I got home and loaded the .BIT file onto the board...it works perfectly. [1:0]sw is changing the frequency the the led is blinking at properly. So this tells me that I don't quite have my testbed code done properly. I tried to attach it into this text but it kept getting reformatted so I've simply attached the actual file. If somebody could look at it and tell me what (if anything) I've done wrong I'd greatly appreciate it. THANKS! NOTE: In the actual module code, above, I had changed the CASE choices to the 0, 1st, 2nd and 3rd flip-flops in order to better see the led changing value on the wave panel. However I've changed the code back to the actual flip-flops I wanted; the 26th, 25th, 24th and 23rd flip-flops. As I said...the board is working perfectly now and the switch setting are appropriately changing the led blinking frequency. It HAS to be something wrong with the TestBench code...or me not using the simulator properly. THANKS MUCH! clock_divider.tb
  35. 1 point
    jpeyron

    VGA on Zybo

    Hi @Mukul, Here is a VHDL VGA project that has pixel clock frequencies for multiple resolutions. Here and here are non-digilent VGA tutorials. Here is a listing for different pixel frequencies and resolutions. best regards, Jon
  36. 1 point
    Hi @Phil_D Try calling to load the workspace and to run script one after the other. subprocess.Popen(['C:/Program Files/Digilent/WaveForms3/WaveForms.exe', 'phase_noise_237.dwf3work']) subprocess.Popen(['C:/Program Files/Digilent/WaveForms3/WaveForms.exe', '-runscript'])
  37. 1 point
    Hi @Jaraqui Peixe, Unfortunately, Digilent does not have the ability to obtain these licenses for you with regards to Xilinx negotiations. I do not doubt that the Spartan 3E Starter Boards you have are as good as new and work as such, but the reality is that last variant of ISE 14.7 that could support the FPGA chips on the Basys 2 and the Spartan 3E (both over 10 years old), was released by Xilinx back in 2013, so active support on these boards is limited as the required software will not install on newer OS's (at least the Windows variants anyway). As @xc6lx45, it is possible to make it work though. What I would probably recommend is looking into the newer 7 series boards, such as the Basys 3 (the most similar to the Basys 2) or if you would want access to more memory than is provided in BRAM, both the Arty A7 and the Nexys A7 have on-board DDR memory. All of these boards work with Microblaze and are supported by the free Vivado WebPACK from Xilinx (which is license-free if that is a factor for you and includes Microblaze). Naturally, there is no guarantee that the Vivado software that supports these Artix 7 FPGA chips will become end-of-life'd, but I can at least say from Digilent's end that I have not heard of this happening in the near future. Thanks, JColvin
  38. 1 point
    Hi, >> We are forced to work in assembly with picoblaze. you might have a look at the ZPU softcore CPU with GCC. The CPU is just a few hundred lines of code but most of its functionality is in software in the crt.o library in RAM. I understand it's quite well tested and has been used in commercial products. Not surprisingly, using an FPGA to implement a processor that then kinda emulates itself in software (aka RISC :) ) is maybe not the most efficient use of silicon - I'm sure it has many strong points but speed is not among them... Unfortunately, the broken-ness of Xilinx' DATA2MEM utility (to update the bitstream with a new .elf file) spoils the fun, at least when I tried in ISE14.7 (segfaults). When it works, the compile/build cycle takes only a second or two. Long-term, porting the processor to a new platform would be straightforward, or even fully transparent if using inferred, device-independent memory. This would also work for a bootloader that is hardcoded into default content in inferred RAM. I might consider this myself as a barebone "hackable" CPU platform strictly for educational purposes.
  39. 1 point
    Hi @askhunter, The top.vhd is already added to the project. If you are wanting this file to be underneath the design_1 then you should right click on the design_1 and select add sources. Then add the vhdl files you would like to add to the design. It might be easier to start with a fresh project. best regards, Jon
  40. 1 point
    jpeyron

    Nexys 2 - transistor part number

    Hi @CVu, Glad to hear that replacing the transistor fix the issue. Thank you for sharing what you did. best regards, Jon
  41. 1 point
    jpeyron

    Nexys 2 - transistor part number

    Hi @CVu, Welcome to the Digilent Forums! Q1 information is below: NTS2101P Single P-Channel Power Mosfet 1.4A, 8VSOT-323 (SC-70) best regards, Jon
  42. 1 point
    kwilber

    NEXYS 3 frequency meter

    The problem is likely in the .ucf file where you define pin information. The error message says device pin LL8 doesn't exist. If you post the contents of your ucf, we can probably figure it out.
  43. 1 point
    Hi @kmesne, We responded to your other question here with some detail, but I will try to elaborate a little bit more here. The Pmod COLOR is not intended to detect colors from any sort of distance, so you would need it next to the red/green light indicator and then have it transmit data to the main controller for the car as opposed to be mounted on the car (unless the red/green indicator was on the car itself). I believe the Pmod COLOR could detect the green in a green cube, but it would need to be fairly well lit up due to the limitations of the sensor itself. As a bit of perspective, this will be a large and non-trivial state machine (especially for first semester project) with a lot of conditions to be covered; is light red or green to control the enable bit on 2+ H-bridge drivers running the motor, which needs to be checked frequently in order to obey traffic laws, as well as the enable bit being toggled as appropriate when changing input directions if the vehicle can go in reverse to avoid burning out the h-bridges, pwm control over the enable pin to allow the vehicle to turn; all done over (presumably) 3 remote systems communicating with each other; the controller with the direction buttons, the color sensor detecting the light change, and the RC vehicle itself. Which system/input will have priority in the state machine and how often will you need to check each input to provide a "smooth driving experience" will all be things that you need to consider. Some good resources for VHDL basics can be found at asic-world.com and fpga4fun.com, as well as this page that discusses state machine construction in VHDL. Thanks, JColvin
  44. 1 point
    You might have a look at Trenz Electronics "Zynqberry". I think they managed to get one of the cameras to work (not sure). What I do remember is that the board has some custom resistor circuitry to additional pins for the required low-speed signaling.
  45. 1 point
    kwilber

    Pmod DA3 clocking

    You may not have to build your own. That becomes a design decision that only you can make based on the requirements/specifications your design must meet. If the performance you are getting out of the Digilent IP meets your requirements, there is no reason to roll your own. On the other hand, if you are not able to meet your requirements and you are running up against limitations of the IP, then either look for a more performant IP or consider designing purpose specific logic. According to your measurements, it takes 40 bits sent at a rate of 3.125 Mhz for each update of the DAC. That is at least 12.8 microseconds per update. Take the inverse of that and you have a maximum update rate of 78,125 updates/second. Is that sufficient for your design?
  46. 1 point
    jpeyron

    Pmod DA3 clocking

    Hi @Ahmed Alfadhel, In section 2 Interfacing with the Pmod on page 1 of the reference manual for the Pmod DA3 here it states the pmod should use spi mode 0. thank you, Jon
  47. 1 point
    Hi @hello.parth, The Ethernet IP cores use the AXI BUS. You would need to implement the AXI BUS communication to interact with the Ethernet IP Cores. This is not an easy task. You do not need to use Microblaze or the Ethernet IP Cores to use the ethernet on the Nexys Video. Here is a community members( @hamster) VHDL GigabitTX project using the Nexys Video. thank you, Jon
  48. 1 point
    D@n

    Conflicting Voltages in Bank Arty-A7

    @zygot, @Ahmed Alfadhel is not using a Basys3 board, and so this is really a bad example of attaching one question to another post. @Ahmed Alfadhel appears to be using an Artix-A7 board. In that case, the sys_clk is properly constrained, but he may well have some of the DDR3 I/O pins improperly constrained. These are the pins located on Bank 35. I think the problem in this case is that @Ahmed Alfadhel has improperly constrained in DDR DQS pins. For example, ddr3_dqs_[0] should be set to pin N2, not to A6. Compounding the problem is the way these pins are hidden in a "board definition file" rather than in the XDC file, making it likely to have conflicting pin definitions. @Ahmed Alfadhel, If you are following Digilent's instructions, you might want to double check that you have the appropriate board definition file. If you are trying this on your own, using only an XDC file, then you might find these instructions valuable. Also, I would recommend you not attach unrelated issues to old posts. Perhaps the Digilent staff might be kind enough to separate these two issues into separate forum posts--since they really are quite different. For example, the Basys3 board doesn't have the DDR3 memory which is the source of your pin-connection troubles. Dan
  49. 1 point
    Hi @neocsc, Here is a verified Nexys Video HDMI project updated from Vivado 2016.4 to Vivado 2017.4. You should be able to find the updated project in the proj folder . Here is a GitHub project done in HDL using the clocking wizard, DVI2RGB and RGB2DVI IP Cores for another FPGA. Here is a unverified Nexys Video Vivado 2017.4 HDMI pass through project made from the linked Github project. In the next few days I should have the bandwidth to verify this project. thank you, Jon
  50. 1 point
    hamster

    MMCM dynamic clocking

    I feel a bit bad about posting a minor novel here, but here is an example of going from "5 cycles on, 5 off" (i.e. divide by 10) to "10 on, 10 off" (device by 20). The VCO is initially to 800 MHz with CLK0 being VCO divide by 8.... so after config you get 100MHz. Push the button and you get 800/20 = 40MHz, release the button and you get 80MHz. It is all really hairy in practice! EDIT: Through experimentation I just found that you don't need to reset the MMCM if you are not changing the VCO frequency. So the 'rst' signal in the code below isn't needed (and LOCKED will stay asserted). -------------------------------------------------------------------------------------------------------- -- Playing with the MMCM DRP ports. -- see https://www.xilinx.com/support/documentation/application_notes/xapp888_7Series_DynamicRecon.pdf -- for the Dynamic Reconviguration Port addresses -------------------------------------------------------------------------------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; library UNISIM; use UNISIM.VComponents.all; entity mmcm_reset is Port ( clk_100 : in STD_LOGIC; btn_raw : in STD_LOGIC; led : out STD_LOGIC_VECTOR (15 downto 0)); end mmcm_reset; architecture Behavioral of mmcm_reset is signal btn_meta : std_logic := '0'; signal btn : std_logic := '0'; signal speed_select : std_logic := '0'; signal counter : unsigned(26 downto 0) := (others => '0'); signal debounce : unsigned(15 downto 0) := (others => '0'); signal clk_switched : std_logic := '0'; signal clk_fb : std_logic := '0'; type t_state is (state_idle_fast, state_go_slow_1, state_go_slow_2, state_go_slow_3, state_idle_slow, state_go_fast_1, state_go_fast_2, state_go_fast_3); signal state : t_state := state_idle_fast; ----------------------------------------------------------------------------- --- This is the CLKOUT0 ClkReg1 address - the only register to be played with ----------------------------------------------------------------------------- signal daddr : std_logic_vector(6 downto 0) := "0001000"; signal do : std_logic_vector(15 downto 0) := (others => '0'); signal drdy : std_logic := '0'; signal den : std_logic := '0'; signal di : std_logic_vector(15 downto 0) := (others => '0'); signal dwe : std_logic := '0'; signal rst : std_logic := '0'; begin MMCME2_ADV_inst : MMCME2_ADV generic map ( BANDWIDTH => "OPTIMIZED", -- Jitter programming (OPTIMIZED, HIGH, LOW) CLKFBOUT_MULT_F => 8.0, -- Multiply value for all CLKOUT (2.000-64.000). CLKFBOUT_PHASE => 0.0, -- Phase offset in degrees of CLKFB (-360.000-360.000). -- CLKIN_PERIOD: Input clock period in ns to ps resolution (i.e. 33.333 is 30 MHz). CLKIN1_PERIOD => 10.0, CLKIN2_PERIOD => 0.0, -- CLKOUT0_DIVIDE - CLKOUT6_DIVIDE: Divide amount for CLKOUT (1-128) CLKOUT1_DIVIDE => 1, CLKOUT2_DIVIDE => 1, CLKOUT3_DIVIDE => 1, CLKOUT4_DIVIDE => 1, CLKOUT5_DIVIDE => 1, CLKOUT6_DIVIDE => 1, CLKOUT0_DIVIDE_F => 8.0, -- Divide amount for CLKOUT0 (1.000-128.000). -- CLKOUT0_DUTY_CYCLE - CLKOUT6_DUTY_CYCLE: Duty cycle for CLKOUT outputs (0.01-0.99). CLKOUT0_DUTY_CYCLE => 0.5, CLKOUT1_DUTY_CYCLE => 0.5, CLKOUT2_DUTY_CYCLE => 0.5, CLKOUT3_DUTY_CYCLE => 0.5, CLKOUT4_DUTY_CYCLE => 0.5, CLKOUT5_DUTY_CYCLE => 0.5, CLKOUT6_DUTY_CYCLE => 0.5, -- CLKOUT0_PHASE - CLKOUT6_PHASE: Phase offset for CLKOUT outputs (-360.000-360.000). CLKOUT0_PHASE => 0.0, CLKOUT1_PHASE => 0.0, CLKOUT2_PHASE => 0.0, CLKOUT3_PHASE => 0.0, CLKOUT4_PHASE => 0.0, CLKOUT5_PHASE => 0.0, CLKOUT6_PHASE => 0.0, CLKOUT4_CASCADE => FALSE, -- Cascade CLKOUT4 counter with CLKOUT6 (FALSE, TRUE) COMPENSATION => "ZHOLD", -- ZHOLD, BUF_IN, EXTERNAL, INTERNAL DIVCLK_DIVIDE => 1, -- Master division value (1-106) -- REF_JITTER: Reference input jitter in UI (0.000-0.999). REF_JITTER1 => 0.0, REF_JITTER2 => 0.0, STARTUP_WAIT => FALSE, -- Delays DONE until MMCM is locked (FALSE, TRUE) -- Spread Spectrum: Spread Spectrum Attributes SS_EN => "FALSE", -- Enables spread spectrum (FALSE, TRUE) SS_MODE => "CENTER_HIGH", -- CENTER_HIGH, CENTER_LOW, DOWN_HIGH, DOWN_LOW SS_MOD_PERIOD => 10000, -- Spread spectrum modulation period (ns) (VALUES) -- USE_FINE_PS: Fine phase shift enable (TRUE/FALSE) CLKFBOUT_USE_FINE_PS => FALSE, CLKOUT0_USE_FINE_PS => FALSE, CLKOUT1_USE_FINE_PS => FALSE, CLKOUT2_USE_FINE_PS => FALSE, CLKOUT3_USE_FINE_PS => FALSE, CLKOUT4_USE_FINE_PS => FALSE, CLKOUT5_USE_FINE_PS => FALSE, CLKOUT6_USE_FINE_PS => FALSE ) port map ( -- Clock Outputs: 1-bit (each) output: User configurable clock outputs CLKOUT0 => clk_switched, CLKOUT0B => open, CLKOUT1 => open, CLKOUT1B => open, CLKOUT2 => open, CLKOUT2B => open, CLKOUT3 => open, CLKOUT3B => open, CLKOUT4 => open, CLKOUT5 => open, CLKOUT6 => open, -- Dynamic Phase Shift Ports: 1-bit (each) output: Ports used for dynamic phase shifting of the outputs PSDONE => open, -- Feedback Clocks: 1-bit (each) output: Clock feedback ports CLKFBOUT => clk_fb, CLKFBOUTB => open, -- Status Ports: 1-bit (each) output: MMCM status ports CLKFBSTOPPED => open, CLKINSTOPPED => open, LOCKED => open, -- Clock Inputs: 1-bit (each) input: Clock inputs CLKIN1 => clk_100, CLKIN2 => '0', -- Control Ports: 1-bit (each) input: MMCM control ports CLKINSEL => '1', PWRDWN => '0', -- 1-bit input: Power-down RST => rst, -- 1-bit input: Reset -- DRP Ports: 16-bit (each) output: Dynamic reconfiguration ports DCLK => clk_100, -- 1-bit input: DRP clock DO => DO, -- 16-bit output: DRP data DRDY => DRDY, -- 1-bit output: DRP ready -- DRP Ports: 7-bit (each) input: Dynamic reconfiguration ports DADDR => DADDR, -- 7-bit input: DRP address DEN => DEN, -- 1-bit input: DRP enable DI => DI, -- 16-bit input: DRP data DWE => DWE, -- 1-bit input: DRP write enable -- Dynamic Phase Shift Ports: 1-bit (each) input: Ports used for dynamic phase shifting of the outputs PSCLK => '0', PSEN => '0', PSINCDEC => '0', -- Feedback Clocks: 1-bit (each) input: Clock feedback ports CLKFBIN => clk_fb ); speed_change_fsm: process(clk_100) begin if rising_edge(clk_100) then di <= (others => '0'); dwe <= '0'; den <= '0'; case state is when state_idle_fast => if speed_select = '1'then state <= state_go_slow_1; -- High 10 Low 10 di <= "0001" & "001010" & "001010"; dwe <= '1'; den <= '1'; end if; when state_go_slow_1 => if drdy = '1' then state <= state_go_slow_2; end if; when state_go_slow_2 => rst <= '1'; state <= state_go_slow_3; when state_go_slow_3 => rst <= '0'; state <= state_idle_slow; when state_idle_slow => di <= (others => '0'); if speed_select = '0' and drdy = '0' then state <= state_go_fast_1; -- High 5 Low 5 di <= "0001" & "000101" & "000101"; dwe <= '1'; den <= '1'; end if; when state_go_fast_1 => if drdy = '1' then state <= state_go_fast_2; end if; when state_go_fast_2 => rst <= '1'; state <= state_go_fast_3; when state_go_fast_3 => rst <= '0'; state <= state_idle_fast; end case; end if; end process; dbounce_proc: process(clk_100) begin if rising_edge(clk_100) then if speed_select = btn then debounce <= (others => '0'); elsif debounce(debounce'high) = '1' then speed_select <= not speed_select; else debounce <= debounce + 1; end if; -- Syncronise the button btn <= btn_meta; btn_meta <= btn_raw; end if; end process; show_speed_proc: process(clk_switched) begin if rising_edge(clk_switched) then counter <= counter + 1; led(7 downto 0) <= std_logic_vector(counter(counter'high downto counter'high-7)); end if; end process; led(15) <= speed_select; end Behavioral;