engrpetero

Newcomers
  • Content Count

    19
  • Joined

  • Last visited

About engrpetero

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I've been making reasonable (good, even) progress with the Vitis IDE and the ZyboZ7. A question though about clocks on this board and their interface to the Zybo. I've been using the xscutimer module in interrupt mode. However, I'm struggling to figure out appropriate values for the TIME_LOAD_VALUE. If I set it to a pretty high number (hex FFFF FFFF) (dec 4,294,967,295), I see events happen at about 0.8s. If I set it to 9FFF FFFF (dec 2,684,354,559), I see an event about every 0.5s (they scaled pretty linearly). Since I believe the timer is just counting this many clock cycles, it seems the clock is way too high - somewhere around 5.3E9 (or I'm not sure how to set this value). I've looked at the Zybo reference docs and seem some references to clocks (667Mhz). I will look further at the Arm9 cortex reference to gain some insight. But if anyone can help me out, much appreciated. Peter
  2. Hi JColvin. That's somewhat useful. 🙂 I did start a thread over at the Xilinx forum on a design choice. After more studying of the example (and Xilinx UG480 which seems to have been it's basis), it *seems* the configuration is all done with those hex values you mentioned (though I think they are 32 bits wide, not 16?). I do expect to ask a similar instantiation question over there, after a discussion of a design choice and whether custom IP instantiations of the wizard of inclusion of the wizard as a top level block is a better design choice.
  3. Some very useful info is in XIlinx UG480, particularly page 22. https://www.xilinx.com/support/documentation/user_guides/ug480_7Series_XADC.pdf
  4. Finally got back to trying this, JColvin. Still have questions. The 'top' design source in the example is a verilog one. What I missed was the entity xadc_wiz_o in the other design source VHDL file. Since I'm still grappling with hierarchical designs (getting there though!), I'm not sure where it came from (it has a Xilinx header but not sure if the Digilent author of the 'top' design source just included that header. I copied the xadc_wiz_o entity file below to make it easier for me to ask my questions (I might have violated a message board rule by copying the whole file - sorry if I did. It makes the questions and answers more useful (I think) to anyone else reading the post)... Not sure what the 'attribute' statements are doing in this example, particularly the second one. I do find it 'neat' that once the component is instantiated, everything about the block source configuration UI is available. Can anyone provide a brief comment on these two lines? I assume the designer of this project created the xadc_wiz_o entity (and file) in which an XADC component is instantiated. The library 'UNISIM' and the package that includes UNISIM.VCOMPONENTS.ALL... that is the item I can't seem to find if I want to use this entity file (or a similar one) in my project. How would I include the appropriate libraries/references in my project? Peter library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; Library UNISIM; use UNISIM.VCOMPONENTS.ALL; entity xadc_wiz_0 is port ( daddr_in : in STD_LOGIC_VECTOR (6 downto 0); -- Address bus for the dynamic reconfiguration port den_in : in STD_LOGIC; -- Enable Signal for the dynamic reconfiguration port di_in : in STD_LOGIC_VECTOR (15 downto 0); -- Input data bus for the dynamic reconfiguration port dwe_in : in STD_LOGIC; -- Write Enable for the dynamic reconfiguration port do_out : out STD_LOGIC_VECTOR (15 downto 0); -- Output data bus for dynamic reconfiguration port drdy_out : out STD_LOGIC; -- Data ready signal for the dynamic reconfiguration port dclk_in : in STD_LOGIC; -- Clock input for the dynamic reconfiguration port vauxp6 : in STD_LOGIC; -- Auxiliary Channel 6 vauxn6 : in STD_LOGIC; vauxp7 : in STD_LOGIC; -- Auxiliary Channel 7 vauxn7 : in STD_LOGIC; vauxp14 : in STD_LOGIC; -- Auxiliary Channel 14 vauxn14 : in STD_LOGIC; vauxp15 : in STD_LOGIC; -- Auxiliary Channel 15 vauxn15 : in STD_LOGIC; busy_out : out STD_LOGIC; -- ADC Busy signal channel_out : out STD_LOGIC_VECTOR (4 downto 0); -- Channel Selection Outputs eoc_out : out STD_LOGIC; -- End of Conversion Signal eos_out : out STD_LOGIC; -- End of Sequence Signal alarm_out : out STD_LOGIC; -- OR'ed output of all the Alarms vp_in : in STD_LOGIC; -- Dedicated Analog Input Pair vn_in : in STD_LOGIC ); end xadc_wiz_0; architecture xilinx of xadc_wiz_0 is attribute CORE_GENERATION_INFO : string; attribute CORE_GENERATION_INFO of xilinx : architecture is "xadc_wiz_0,xadc_wiz_v3_3_7,{component_name=xadc_wiz_0,enable_axi=false,enable_axi4stream=false,dclk_frequency=125,enable_busy=true,enable_convst=false,enable_convstclk=false,enable_dclk=true,enable_drp=true,enable_eoc=true,enable_eos=true,enable_vbram_alaram=false,enable_vccddro_alaram=false,enable_Vccint_Alaram=false,enable_Vccaux_alaram=falseenable_vccpaux_alaram=false,enable_vccpint_alaram=false,ot_alaram=false,user_temp_alaram=false,timing_mode=continuous,channel_averaging=None,sequencer_mode=on,startup_channel_selection=contineous_sequence}"; signal FLOAT_VCCAUX_ALARM : std_logic; signal FLOAT_VCCINT_ALARM : std_logic; signal FLOAT_USER_TEMP_ALARM : std_logic; signal FLOAT_VBRAM_ALARM : std_logic; signal FLOAT_MUXADDR : std_logic_vector (4 downto 0); signal aux_channel_p : std_logic_vector (15 downto 0); signal aux_channel_n : std_logic_vector (15 downto 0); signal alm_int : std_logic_vector (7 downto 0); begin alarm_out <= alm_int(7); aux_channel_p(0) <= '0'; aux_channel_n(0) <= '0'; aux_channel_p(1) <= '0'; aux_channel_n(1) <= '0'; aux_channel_p(2) <= '0'; aux_channel_n(2) <= '0'; aux_channel_p(3) <= '0'; aux_channel_n(3) <= '0'; aux_channel_p(4) <= '0'; aux_channel_n(4) <= '0'; aux_channel_p(5) <= '0'; aux_channel_n(5) <= '0'; aux_channel_p(6) <= vauxp6; aux_channel_n(6) <= vauxn6; aux_channel_p(7) <= vauxp7; aux_channel_n(7) <= vauxn7; aux_channel_p(8) <= '0'; aux_channel_n(8) <= '0'; aux_channel_p(9) <= '0'; aux_channel_n(9) <= '0'; aux_channel_p(10) <= '0'; aux_channel_n(10) <= '0'; aux_channel_p(11) <= '0'; aux_channel_n(11) <= '0'; aux_channel_p(12) <= '0'; aux_channel_n(12) <= '0'; aux_channel_p(13) <= '0'; aux_channel_n(13) <= '0'; aux_channel_p(14) <= vauxp14; aux_channel_n(14) <= vauxn14; aux_channel_p(15) <= vauxp15; aux_channel_n(15) <= vauxn15; U0 : XADC generic map( INIT_40 => X"0000", -- config reg 0 INIT_41 => X"21AF", -- config reg 1 INIT_42 => X"0500", -- config reg 2 INIT_48 => X"0800", -- Sequencer channel selection INIT_49 => X"C0C0", -- Sequencer channel selection INIT_4A => X"0000", -- Sequencer Average selection INIT_4B => X"0000", -- Sequencer Average selection INIT_4C => X"0000", -- Sequencer Bipolar selection INIT_4D => X"0000", -- Sequencer Bipolar selection INIT_4E => X"0000", -- Sequencer Acq time selection INIT_4F => X"0000", -- Sequencer Acq time selection INIT_50 => X"B5ED", -- Temp alarm trigger INIT_51 => X"57E4", -- Vccint upper alarm limit INIT_52 => X"A147", -- Vccaux upper alarm limit INIT_53 => X"CA33", -- Temp alarm OT upper INIT_54 => X"A93A", -- Temp alarm reset INIT_55 => X"52C6", -- Vccint lower alarm limit INIT_56 => X"9555", -- Vccaux lower alarm limit INIT_57 => X"AE4E", -- Temp alarm OT reset INIT_58 => X"5999", -- Vccbram upper alarm limit INIT_5C => X"5111", -- Vccbram lower alarm limit INIT_59 => X"5555", -- Vccpint upper alarm limit INIT_5D => X"5111", -- Vccpint lower alarm limit INIT_5A => X"9999", -- Vccpaux upper alarm limit INIT_5E => X"91EB", -- Vccpaux lower alarm limit INIT_5B => X"6AAA", -- Vccddro upper alarm limit INIT_5F => X"6666", -- Vccddro lower alarm limit SIM_DEVICE => "ZYNQ", SIM_MONITOR_FILE => "design.txt" ) port map ( CONVST => '0', CONVSTCLK => '0', DADDR(6 downto 0) => daddr_in(6 downto 0), DCLK => dclk_in, DEN => den_in, DI(15 downto 0) => di_in(15 downto 0), DWE => dwe_in, RESET => '0', VAUXN(15 downto 0) => aux_channel_n(15 downto 0), VAUXP(15 downto 0) => aux_channel_p(15 downto 0), ALM => alm_int, BUSY => busy_out, CHANNEL(4 downto 0) => channel_out(4 downto 0), DO(15 downto 0) => do_out(15 downto 0), DRDY => drdy_out, EOC => eoc_out, EOS => eos_out, JTAGBUSY => open, JTAGLOCKED => open, JTAGMODIFIED => open, OT => open, MUXADDR => FLOAT_MUXADDR, VN => vn_in, VP => vp_in ); end xilinx;
  5. Hoping for a bit of explanation on this example. I've been focused on VHDL, not verilog (which looks like the language of this sample). Question... how does the module 'top' know of the existence of myxadc (which is an instantiation of xadc_wiz_0 (or vice versa since I'm not sure the order of verilog statements))? IOW, I don't see a reference, include, using, etc... module top( input clk, input [7:0] ja, output [3:0] led ); reg [6:0] daddr = 0; // address of channel to be read reg [1:0] ledidx = 0; // index of the led to capture data for wire eoc; // xadc end of conversion flag wire [15:0] dout; // xadc data out bus wire drdy; reg [1:0] _drdy = 0; // delayed data ready signal for edge detection reg [7:0] data0 = 0, // stored XADC data, only the uppermost byte data1 = 0, data2 = 0, data3 = 0; reg [7:0] pwm_count; // shared pwm counter reg [7:0] pwm_duty0; // duty cycles for the 4 pwm led brightness controllers reg [7:0] pwm_duty1; reg [7:0] pwm_duty2; reg [7:0] pwm_duty3; xadc_wiz_0 myxadc ( .dclk_in (clk), .den_in (eoc), // drp enable, start a new conversion whenever the last one has ended .dwe_in (0), .daddr_in (daddr), // channel address .di_in (0), .do_out (dout), // data out .drdy_out (drdy), // data ready .eoc_out (eoc), // end of conversion .vauxn6 (ja[7]), .vauxp6 (ja[3]), .vauxn7 (ja[5]), .vauxp7 (ja[1]), .vauxn14 (ja[4]), .vauxp14 (ja[0]), .vauxn15 (ja[6]), .vauxp15 (ja[2]) ); [email protected](posedge clk) _drdy <= {_drdy[0], drdy}; [email protected](*) case (ledidx) 0: daddr = 7'h1E; 1: daddr = 7'h17; 2: daddr = 7'h1F; 3: daddr = 7'h16; default: daddr = 7'h1E; endcase [email protected](posedge clk) begin if (_drdy == 2'b10) begin // on negative edge ledidx <= ledidx + 1; case (ledidx) 0: data0 <= dout[15:8]; 1: data1 <= dout[15:8]; 2: data2 <= dout[15:8]; 3: data3 <= dout[15:8]; endcase end end [email protected](posedge clk) pwm_count <= pwm_count + 1; [email protected](posedge clk) if (pwm_count == 0) begin pwm_duty0 <= data0; pwm_duty1 <= data1; pwm_duty2 <= data2; pwm_duty3 <= data3; end assign led[0] = (pwm_count <= pwm_duty0) ? 1 : 0; assign led[1] = (pwm_count <= pwm_duty1) ? 1 : 0; assign led[2] = (pwm_count <= pwm_duty2) ? 1 : 0; assign led[3] = (pwm_count <= pwm_duty3) ? 1 : 0; endmodule
  6. engrpetero

    Zybo example with...

    So I've made a pretty simple IP block in a Zybo design that also contains a Zynq processing system IP. I'm interested in the button presses and slide switches to serve as inputs to both the PL and PS and to control the LEDS - 2 each - from the PL and PS. Struggling to figure out how to get the connections for this. Can anyone point me to a tutorial (or sample project) for the Zybo that does something similar, please? (I should have mentioned I'm using Vivado 2019.2 and whatever the current Vitis is).
  7. Hi Ana-Maria, I forgot to respond to your post (though do thank you for your response). Not sure why the light-bulb didn't go off before. Peter
  8. Thanks, JColvin. FWIW, I have the -10 version of the ZYboZ7. The example you pointed to was somewhat helpful. I need to study it a bit more but think it will be very useful. In the meantime - and because I need to do it anyway as part of this simple design - I've moved back to connecting a simple custom IP block to a Zynq and continue to have some issues. I'll ask in another thread if someone can point me to an example.
  9. Still drinking from the firehose... It's taken a week for the lightbulb to go off with respect to Vivado board files, particularly the board file for the ZyboZ7. When creating a new design, with this board file as the basis, I've only now realized that when I add a Zynq7 Processing system as IP, the 'default' settings (things enabled, and their 'properties') are always the same. Surely this is coming from the board file (well, files since there are 3 of them) for if I just create a design with the same FPGA as found on the Zybo, the Zynq7 Processing system IP is different. Assuming this to be right, my question is... In general, it seems that at if I screw around with IO Peripherals, I'm likely to make things not work with this board, right? For example, based on the picture below (which contains the 'defaults')... If I change the UART1 MIO from the default (MIO 48...49) to something else, then since the MIO 48 and 49 pins are what's actually physically routed to the FTDI chip and then the USB/UART connector, I wouldn't be able to communicate with the UART over the Zybo connector. Same would apply to the GPIO pins next in the MIO configuration page?
  10. closer. Have reviewed the example main (used the 4.1 version). Got a response on my terminal application. Moved on to the 'xuartps_intr_example.c file, using it's main with the original Blinky app (and it's hardware config). Don't see any traffic at all over the uart with this example (I have made no changes - the posts I find online about ensuring 'XPAR_XUARTPS_0_INTR' and not 'XPAR_XUARTPS_1_INTR' were already present in the file in this example supplied with the 2019.2 Vitis. I do note (not sure it matters) that when I click on the Zynq block in the Vivado project that contained that was used for the Blinky example, the UART0 does not have a check next to it (however, that didn't seem to matter when data was sent from the xscugic_example file. Any ideas or pointers?
  11. Sometimes, all you need to do is post and then you find part of the answer! 🙂 Searching my computer for the header file scugic.h returned lots of instances, particularly an example using the V3.8 version of this driver. I chose the default directories when installing and I found this example at the following location. file:///C:/Xilinx/Vitis/2019.2/data/embeddedsw/XilinxProcessorIPLib/drivers/scugic_v3_8/doc/html/api/xscugic__example_8c.html Last question in initial post still applies. Are there other options I should consider for interrupts?
  12. Hi All, I've been actively searching the forums here and over at Xilinx. Still working on some portions of my Zybo project and getting more capable with the Zynq processor and the FPGA capabilities. Sometimes, searches take me down rabbit holes and/or to dead-ends (part of the nature of fora, I guess). One thing in particular I'm trying to find more info on is useful ways/best practices for handling interrupts for the Zynq (want to setup interrupts for UART receive and then on some GPIO that the FPGA portion of the Zynq is also using). I've seen references to xscugic which seems to have been documented (somewhat?) in the old Xilinx SDK (which I can't find anywhere to download still). Is this interrupt framework/controller still useful and if so, can anyone point me to documentation (and perhaps a sample project)? Are there other options I should consider for interrupts? Peter
  13. Oh - I definitely have a space in the path name. I moved things to a new folder with no spaces anywhere in the path. That got me by the 'Next' button. I can continue the exercise. Much thanks for the help, JColvin!
  14. Hmmm... I think I have the same name as you've shown ('design_1_wrapper [custom]'). There is a space between the 'r' in wrapper and the text [custom] but I don' think that's different from what you showed. Interestingly, if I choose one of the already displayed choices - 'zed' for example - I can get by the 'Next' button. Perhaps trying the quick start all over again to see if I get any different result...
  15. Your second screen shot was very helpful. I see the same thing as on your first screenshot. I thin click 'Next' and I think Vitis tries to show the progress bar you've shown in the second picture. However, it happens so fast, I never really see the progress bar. Then I'm just put back to the first screenshot picture but the 'Next' button is greyed out. I found another post on this forum (I think from you!) that contained a Vitis IDE (zipped) for an arty_z7_20_base. I could open that in Vitis and look around with it. So in some ways, it seems Vitis is working. I just can't get by that first screen.