• Content count

  • Joined

  • Last visited

Everything posted by tofu

  1. hi magnus, thanks for the response. while i didn't mention it, i had tried just about every permutation (valid and non-valid syntax) of making these array assignments between wishbone-in<->wb_dat_i possible. i had also tried it like you mentioned, but it unfortunately doesn't seem to change that a single wire is being connected rather than 32 of them. please see this screenshot from planahead of what the syntax you posted above looks like. i'm planning on looking at a few other wishbone peripherals from designlab later tonight, to better understand how planahead represents arrays of wires. thanks, -matt
  2. hi, i'm using designlab 1.0.8 with ise 14.7 on ubuntu 17.04 amd64, targeting a papilio pro/spartan 6 with the zpuino soft processor. i've got a working proof-of-concept design which combines a few bits and pieces, namely the whirlyfly (whirlygig) random number generator (, a couple wishbone uart's (COMM_zpuino_wb_UART.vhd), and a wishbone watchdog peripheral written in verilog that i've been trying to integrate ( the rng and uart components appear to be working fine, giving me up to 280KB/s or so of random data when polling both wishbone uart's sequentially at 3mbit/s. i'm then using the reference blake2s hash implementation ( to further "whiten" the output of the rng's. this slows down the output to about 30KB/s which is fine considering it's a complex operation. that's not the issue. anyhow, the wishbone peripherals included in designlab, as well as the schematic representation of the zpuino 2.0 soft processor bundle the input and output wires into the wishbone_in/wishbone_out connections, which i assume is for simplicity when placing components using the schematic editor in ise. the watchdog.v implementation linked previously is designed with all of the wishbone wires broken out like: module watchdog(wb_clk_i, wb_rst_i, wb_dat_i, wb_dat_o, wb_we_i, wb_stb_i, wb_cyc_i, wb_ack_o, wb_int_o); i've been trying unsuccessfully now for a while to modify the watchdog.v to present the same interface, so i can easily attach it to the zpuino using the schematic editor gui (i.e. Papilio_Pro.sch) in ise. without knowing how to modify the schematic symbol after generating it, i just took the one from the wishbone uart included in designlab, replaced the relevant variables and removed the tx/rx, and overwrote the existing watchdog.sym in the project directory. that seemed to work fine and let me drag & drop the watchdog onto an open wishbone port on the zpuino. the issue i'm having is that i can't seem to get the pre-synthesis rtl schematic viewer in planahead to "alias" the slices of wishbone_in/wishbone_out to the friendly-named wires representative of their function within the wishbone bus (e.g. wire [31:0] wb_dat_i; assign wb_dat_i [31:0] = wishbone_in [59:28];). the design does synthesize fine, but i haven't bothered trying to write C code for the zpuino to interface/write with the watchdog peripheral because of the apparent brokenness being shown in planahead. here's a simplification of what i've been doing unsuccessfully to create the "friendly" aliases of wishbone_in/wishbone_out: // original, simplified module watchdog(wb_clk_i, wb_rst_i, wb_dat_i, ...); parameter Tp = 1; input wb_clk_i; input wb_rst_i; input [`WDT_WIDTH - 1:0] wb_dat_i; ... // new, simplified module watchdog(wishbone_in, wishbone_out); parameter Tp = 1; input [100:0] wishbone_in; output [100:0] wishbone_out; wire wb_clk_i = wishbone_in [61]; wire wb_rst_i = wishbone_in [60]; wire [31:0] wb_dat_i; assign wb_dat_i [31:0] = wishbone_in [59:28]; ... // mutual code between original & new ... always @(posedge wb_rst_i or posedge wb_clk_i) if (wb_rst_i) begin stb <= #Tp 1'b0; we <= #Tp 1'b0; dat_ir <= #Tp `WDT_WIDTH'h0; end else begin stb <= #Tp wb_stb_i && wb_cyc_i; we <= #Tp wb_we_i; dat_ir <= #Tp wb_dat_i; end ... attached are abridged screenshots of what planahead shows for the unmodified verilog code straight from the aforementioned github repo (top image), and the seemingly broken output from my modified version where i try to bundle up the wires into wishbone_in/wishbone_out. the dat_ir is where wb_dat_i is showing a single wire instead of [31:0]. also attached is the work-in-progress modified watchdog.v. please keep in mind that these are the first lines of vhdl/verilog i've ever written so my knowledge of syntax/terminology is very limited. thanks! watchdog.v
  3. hi jack, thanks for trying to understand my poorly described issue. i don't speak the "language" so i'm probably not using proper terms anywhere... the vhdl wishbone peripherals provided in the designlab ide have their wires unpacked like so (taken verbatim from COMM_zpuino_wb_UART.vhd): -- Unpack the wishbone array into signals so the modules code is not confusing. wb_clk_i <= wishbone_in(61); wb_rst_i <= wishbone_in(60); wb_dat_i <= wishbone_in(59 downto 28); wb_adr_i <= wishbone_in(27 downto 3); the watchdog peripheral i found on opencores is written in verilog, and it does not "unpack the wishbone array". my efforts thus far have been to try to adapt the watchdog so i can create a symbol then drag & drop it onto one of the zpuino's wishbone slots using the gui schematic editor. the examples included in designlab are bundled into an 101 signal array like: wishbone_in : in std_logic_vector(100 downto 0); wishbone_out : out std_logic_vector(100 downto 0); the issue i'm having is that no matter what i've attempted, the schematic looks incorrect in planahead pre-synthesis. when i try to split up the 101 element array into a smaller array (e.g. 32 address lines and 32 data lines), the wires don't connect properly. instead of the 32 signals in wb_dat_i and wb_addr_i, it only shows *one* signal. i can't get it to show a 32<->32 connection. it always does 32<->1. that's incorrect. i figured it might be just a display/rendering issue in planahead, but i think i'm just doing something wrong. the gist of the verilog code is that i'm trying to use is this: input [100:0] wishbone_in; assign wb_dat_i [31:0] = wishbone_in [59:28]; the "equivalent" working vhdl from designlab uart is this: wishbone_in : in std_logic_vector(100 downto 0); signal wb_dat_i: std_logic_vector(31 downto 0); wb_dat_i <= wishbone_in(59 downto 28) so, for some reason i can't properly connect the array from wishbone_in[59:28] to wb_dat_i[31:0]. it only connects the one signal at position #28 in the array, instead of all 32. the image attached below (which i crudely drew on) shows what i see in planahead. i did watch the video and i suppose i could make multiple bus taps to the wishbone slot, then map the i/o on the unmodified opencores watchdog to them. i'm not sure if i can make multiple bus taps to the same wishbone slot connection? i might try that if what i've been attempting doesn't pan out. thanks again for taking the time to help! -matt
  4. bump i kind of put the project on hold due to this but i'd still like to get the watchdog working -matt
  5. hi jack, thanks for the reply. that is how i originally generated the symbol for the watchdog peripheral. the wishbone_in/wishbone_out were at left and right sides though, not combined on top with the correct spacing. i did that so i could drag/drop without having to mess around with editing X/Y coordinates of the symbol and so forth. however, my issue is that, for example, on dat_ir, "d" shows as just "28", not "[59:28]". it's only attaching a single input rather than the entire array slice. the attached image shows what i'm referring to. thanks, -matt
  6. Hi, I just received a Papilio Pro from LinkSprite today. It is detected as an FTDI device under linux and two serial ports (ttyUSB0, and ttyUSB1) are created when I plug it in. The red led on the board is lit. The jumper is set to 'USB'. The cable works fine with other FTDI devices that I have. When I try to use ./tools/Papilio_Loader/papilio-loader.jar to load the Quickstart-Papilio_Pro_LX9-v1.5.bit file, I get: 'Could not access USB device 0403:6010. If this is linux then use sudo.'. That happens even running it with sudo. When I run the papilio-prog program, I get the following: matt@aquos:~/devel/papilio/DesignLab-1.0.7$ ./hardware/tools/papilio/papilio_loader/papilio-prog -r Using built-in device list Invalid chain position 0, position must be less than 0 (but not less than 0). matt@aquos:~/devel/papilio/DesignLab-1.0.7$ ./hardware/tools/papilio/papilio_loader/papilio-prog -c Using built-in device list Invalid chain position 0, position must be less than 0 (but not less than 0). Response incompatible with mask xxxx01 ISC_Done = 0 ISC_Enabled = 0 House Cleaning = 0 DONE = 0 matt@aquos:~/devel/papilio/DesignLab-1.0.7$ ./hardware/tools/papilio/papilio_loader/papilio-prog -C Using built-in device list Invalid chain position 0, position must be less than 0 (but not less than 0). STAT Register ID_ERROR = 0 IDCODE not validated. DONE = 0 Input from the DONE pin. INIT = 0 Input from the INIT pin. MODE = 000b Input from the MODE pins (M2:M0). GHIGH_B = 0 0 = asserted. GWE = 0 0 = all FFs and Block RAMs are write-disabled. GTS_CFG = 0 0 = all I/Os are 3-stated. IN_ERROR = 0 Legacy input error. DCI_MATCH = 0 DCI is matched. DCM_LOCK = 0 DCMs are locked. CRC_ERROR = 0 CRC error. cycleTCK in TEST_LOGIC_RESET When I try to use papilio-prog with the '-d' option, I get: matt@aquos:~/devel/papilio/DesignLab-1.0.7$ sudo ./hardware/tools/papilio/papilio_loader/papilio-prog -j -d /dev/ttyUSB1 Could not access USB device 0403:6010. If this is linux then use sudo. matt@aquos:~/devel/papilio/DesignLab-1.0.7$ sudo ./hardware/tools/papilio/papilio_loader/papilio-prog -j -d /dev/ttyUSB0 Could not access USB device 0403:6010. If this is linux then use sudo. I will also add, that I have tried this from Windows (well, in a Win 10 kvm, using usb passthrough (which I will say works fine flashing firmwares on other devices)) with the same results. Is there anything I can do to bring this to life? Tools at my disposal are a Bus Pirate, FTDI usb<->serial, and an oscilloscope. Thanks, -Matt
  7. I figured out what the issue was. There was a piece of silkscreen on the bottom (4x via beneath C49, top left corner) that was flaked off. And also the tip of the skinniest part of the groundplane next to the standoff was exposed. Adding the standoff then shorted Vin to Gnd. The via on the bottom seemed to bring Vin from C49 to pins 2 & 3 (RUN1 & MODE) of the regulator on the top side. So I think it is probably OK? What do you think? Add some electrical tape to prevent the short and move on...? Thanks, -Matt