Gra

Members
  • Content Count

    33
  • Joined

  • Last visited

About Gra

  • Rank
    Frequent Visitor

Profile Information

  • Location
    New Zealand

Recent Profile Visitors

1117 profile views
  1. Hi Allan, I see you've got the right idea about the clock paths, and you've been re-formatting your hdl syntax too, it now looks much more like that recommend by Xilinx. If you are not doing so already, I'd recommend you take a look at the constraints, and note that there is a sequence that they should be in, its like this... Constraints Sequence ## Timing Assertions Section # Primary clocks # Virtual clocks # Generated clocks # Clock Groups # Bus Skew constraints # Input and output delay constraints ## Timing Exceptions Section # False Paths # Max Delay / Min Delay # Multicycle Paths # Case Analysis # Disable Timing ## Physical Constraints Section # located anywhere in the file, preferably before or after the timing constraints # or stored in a separate constraint file I think the Xilinx video on the constraints wizard is worth watching, and the wizard topic help is good. https://www.xilinx.com/video/hardware/using-vivado-timing-constraint-wizard.html Just to add, when possible, I like to keep a circuit in mind when I'm writing HDL, then keep an eye on the RTL schematic to check it's building what is expected. This usually works well, but it can be a little buggy (much better than it was). If the RTL schematic looks strange, check the technology schematic before you try to fix it. This technology schematic is normally a true representation of what you'll get. As an example of this I'll upload a couple of pictures from your design (see the slow clock). Primitives. I'd also recommend getting familiar with the primitives in the device you are using. One advantage is you can use your hdl to infer rather than instantiate what you want, another is you can improve performance. Hope thats helpful, Kind Regards Graham
  2. Hello Allan, Your post said you were new to FPGAs and VHDL, despite this you had figured out that the tool was dropping parts of your design during syntheses, and you knew which parts it was dropping too. That's impressive for someone new to this, its fundamental, and that's why I assumed you were probably an experienced engineer working in a new area. I guess you know this... There is a principle that is used by the educated and experienced, its called "see one, do one, teach one". That's what I did, I simply showed you how I'd do something on the FPGA, I think you'll take a look at it, and quickly learn what you need to know, to understand why I've done it that way I think we both know it wasn't a "fix" I uploaded (and I don't think you were trying to get someone to simply fix your project). I showed you how I'd instantiate a primitive that would allow you to control the clock without pushing it out of the clocking circuits, and that the input should be registered. aka "see one" Kind Regards Graham
  3. Hi Allan, Just had to pop out and walk the dog... I've updated your file, attached. I've put some schematics on there so you can see the changes I made, don't forget to take that line out of the xdc too. Does that make it do what you wanted it to do? I've just noticed your "counter process" too, synthesis may just take that as an instruction to invert CLK_4_RAW, possibly clock it with CLK_IN, is that bit working? Kind Regards Graham RAD_counter.vhd
  4. Hi Allan Also, It did pass Synthesis after I added set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets HAM_IN_IBUF]; into the xdc (not a recommended thing to do) Kind Regards Graham
  5. Hi Allan Ugly is fine, but it will mess with the syntheses quite a lot, using a clock buffer with an enable would do the trick. Kind Regards Graham
  6. Hi Allan, I think the first thing you should do with the project is stop gateing HAM_IN with a clock. (cycles_raw <= HAM_IN and clk_cycles). Kind Regards Graham
  7. I see, thanks jpeyron
  8. I’m a little confused about the I/O direction of the USB-UART bridge on the Arty A7 35. The following is how I think its rigged, does this look right to you guys? The uart_rxd_out (port name in the xdc): This is data received by the UART from the USB side of the bridge, so it’s an output from the UART side of the bridge and an input to the FPGA. The uart_txd_in ( port name in the xdc): This is data transmitted by the UART over the bridge to the USB, so its an input on the UART side of the bridge and an output from the FPGA. Or do I have it the wrong way around? Thanks for your help Gra
  9. Hello Pavel, I think you may be trying to carry out a partial FPGA re-configuration. I was doing this some time ago,, so cant remember exact details.. I guess it was maybe 7 years ago with ISE, and I did a little bit of this with Vivado a couple of years ago, but the recent stuff was mainly to do with configuring a small part of the FPGA (then activating it) to meet critical system interface timing demands, I guess that was partial configuration rather than partial re-configuration πŸ™‚ . Funny how we go from, re-configure to save silicone to pre-configure to save time eh Pavel πŸ™‚ Perhaps a good place to look is search the Xilinx site for "Partial reconfiguration controller" I recall using it and I think there a a number of tools, all Xilinx IP.. Hope that helps Gra
  10. Hi RipCityBassWorks.. I wanted to know how it was going so I thought I'd send you the UG link.. πŸ™‚ ... You know how engineers are, we always want to know what the problem was πŸ™‚ In my experience a float often goes high or low, it doesn't really flip frequently over time, but I guess it may do that with this device. Floating wouldn't change a registered value, assuming all the buttons are doing this, perhaps you have no bank power, are the slide switches doing the same thing? Gra
  11. Hi RipCityBassWorks.. You will find it in Xilinx UG912 page 308 https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug912-vivado-properties.pdf Gra
  12. Sounds like something is floating. I suggest you test it by.. Use VHDL to simply connect the buttons to the LED's, check your on the right pins πŸ™‚.. If it's still floating around then add a pulldown to each button net in your XDC you could then change to pullups and check the results. Gra
  13. Hi MTlabhishek, I took a really quick look at the schematic, looks like the max power out on that converter is a little under 5W, so you shouldn't be seeing 2 amps in at 5V. I'd start by re-loading a reference design and measure the current again. Your design can change the power drawn, design errors can also cause large currents to flow. Gra
  14. Piasa, it was actually an example to show a loop, not to demonstrate the best way to describe a shift register. Gra
  15. its just a way of reducing the amount of HDL you have to type Here is an example, say you want to describe a shift register, you have an input and an output data pin, say input_port : std_logic; output_port : std_logic; you are going to need some flipflops for your shift register, lets have 8, you need an input to each flipflop and an output from each flipflop, here are some sigs for that input_signal : std_logic_vector(7 downto 0); output_signal : std_logic_vector(7 downto 0); then you need to describe the flipflops, Process (....) begin if (clk β€˜event and clk = β€˜1’) then output_signal <= input_signal; end if; end process; Now you have 8 individual flipflops with inputs... input_signal(0) input_signal(1) input_signal(2) input_signal(3) input_signal(4) input_signal(5) input_signal(6) input_signal(7) and outputs.... output_signal(0) output_signal(1) output_signal(2) output_signal(3) output_signal(4) output_signal(5) output_signal(6) output_signal(7) So to get your shift register you will need to connect the output of the first flipfloip to the input of the second flipflop and so on.... Then connect your i/o ports, so something like this input_signal(0) <= input_port input_signal(1) <=output_signal(0) input_signal(2) <=output_signal(1) input_signal(3) <=output_signal(2) input_signal(4) <=output_signal(3) input_signal(5) <=output_signal(4) input_signal(6) <=output_signal(5) input_signal(7) <=output_signal(6) output_port <= output_signal(7) All a loop does is compress the notation, the above would do something like this... i = 1 to 7 input_signal(0) <= input_port input_signal(i) <=output_signal(i-1) output_port <= output_signal(7) Useful notation if the shift register was much bigger, or you wanted to change the size easily, also useful in big repetitive circuits like hand crafted filters. Not helpful when you are working in teams and they are used for something as simple as the above, as you can see its easier to read the long-hand description than a loop.. Hope that helps... Gra