DrTrigon

Members
  • Content count

    19
  • Joined

  • Last visited

Community Reputation

0 Neutral

About DrTrigon

  • Rank
    Member

Profile Information

  • Gender Not Telling
  1. Hi Jack, it's been quite some time. Today I did the test of the JTAG variant. One of the reasons why I did not report back for such a long time is that somehow the interplay between DesigLab and Xilinx ISE (Project Navigator, v14.7, lin64) got broken: The edit circuit button in DesignLab does not work anymore for my sketches but for examples (after storing as new sketch of course). Additionaly when I try to open the link sketchdir://circuit/PSL_Papilio_DUO_LX9.xise in my library sketch edit_library.ino file it does not work. But if I run ISE from command line (/opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/ise) and try to open the file .../circuit/PSL_Papilio_DUO_LX9.xise from there, it works for most of them. For some of the .xise files I see a huge bunch of libraries in Design tab opened (not only Papilio_DUO_LX9 and Utility). So to me it looks like the interplay of DesignLab with ISE has issuesmay be some files for ISE are corrupt know (but my git repo shows no changes)Is there a way to reset to "factory settings"? Back to the important part, the test of LogicAnalyzer (JTAG variant): As in papilio-prog (ioftdi.h) the USB VENDOR and DEVICE are hard coded, I had first to the adopt ioftdi.h line 37 to reflect correct DEVICE (use lsusb to be sure, it starts with 0403:....) and then recompile it. After that it worked and as I interpret the output connected correctly, the OLS worked but showed only 'zeros'. Looking at papilio-prog console output showed: [...] Start Capture Taking too long, aborting and just sending zeroes. End Capture Closing socket So what am I doing wrong? Why is the capture taking too long? (I think I tried it w/o trigger as well) Greetings
  2. Hi Jack, Hi Alvie This looks VERY interesting and could have saved me some work! Sounds like it could be exactly what I was looking for. How would the data transfer to the computer be done? Serial line (USB)? Would this occupy the serial bus? Or could it run in parallel to serial debug output? (Does it use the "JTAG channel"?) (Will this enhanced memory through DMA thingy also become available to other Logic Analyzer implementations as well? Or will this Wishbone Logic Analyzer be the recommended variant for future use?) How can I upgrade by DesigLab setup in order to be able to use such a new library/code? Just clone it to the "libraries" folder? Anything else needed? Sorry for asking that many questions at once. May be some are asked to early. Thanks for this new library! Greetings.
  3. Hello Jack! Thanks for your detailed answers! Sorry for not answering - I had a busy time, then holidays and meanwhile a few quadrocopters arrived... ) No, we are not seeing the same thing - you might be confusing "Benchy_Sump_LogicAnalyzer_Standalone" and "Benchy_Sump_LogicAnalyzer" examples. In my DesignLab 1.0.7 (and all my posts) the example you mentioned above is called "Benchy_Sump_LogicAnalyzer". The example called "Benchy_Sump_LogicAnalyzer_Standalone" looks like: and the sketch reads: int counter = 0; void setup() { // put your setup code here, to run once: Serial1.begin(115200); } void loop() { // put your main code here, to run repeatedly: Serial1.write(counter); counter++; delay(1); } (this is the full code, not abbreviated) This is exactly like the Arduino example I was mentioning in a post before, right? So I am still wondering the questions asked before regarding the "Benchy_Sump_LogicAnalyzer_Standalone" as shown here. (especially the rxd, txd, RXD, TXD markers confuse me Good hint thanks! Have to read through this as well. Now I have to sit down and do/test these 2 variants finally... ) Greetings & all the best
  4. ) I exactly know this problem... Oh... cool! Thanks for the links, I had a look at it - this is what I did: download and unpack https://github.com/GadgetFactory/Papilio-Loader/archive/debugMode.zipedit .../Papilio-Loader-debugMode/papilio-prog/progalgspi.cpp, line 957:- int sin_size; + socklen_t sin_size; in order to solve: progalgspi.cpp:995:69: error: invalid conversion from ‘int*’ to ‘socklen_t* {aka unsigned int*}’ [-fpermissive] connected = accept(sock, (struct sockaddr *)&client_addr,&sin_size); then follow instructions in .../Papilio-Loader-debugMode/papilio-prog/README:$ sudo apt-get install git autogen automake g++ libftdi-dev $ ./autogen.sh $ ./configure && make after that I had a binary called .../Papilio-Loader-debugMode/papilio-prog/papilio-prog (not butterflyprog as mentioned in the README). So first thing is to check whether it runs: $ ./papilio-prog -h Usage:./papilio-prog [-v] [-j] [-f <bitfile>] [-b <bitfile>] [-s e|v|p|a] [-c] [-C] [-r] [-A <addr>:<binfile>] -h print this help -v verbose output -j Detect JTAG chain, nothing else -d FTDI device name -f <bitfile> Main bit file -b <bitfile> bscan_spi bit file (enables spi access via JTAG) -s [e|v|p|a] SPI Flash options: e=Erase Only, v=Verify Only, p=Program Only or a=ALL (Default) -c Display current status of FPGA -C Display STAT Register of FPGA -r Trigger a reconfiguration of FPGA -p JTAG passthrough mode -a <addr>:<binfile> Append binary file at addr (in hex) -A <addr>:<binfile> Append binary file at addr, bit reversed Ok, yes it runs and comparing this part of the binary against .../DesignLab-1.0.7/tools/papilio-prog-jtag-server/papilio-prog-jtag-server.exe gives me the impression these are the same programs, right? Now the question to me is how to use this binary? From the links you posted I would be temped to run the -p (passthrough mode) but from the Benchy_Sump_LogicAnalyzer_JTAG example, I would think I have to run it without parameters: For Windows: tools://papilio-prog-jtag-server/papilio-prog-jtag-server.exe Thanks for this hint, are you referring to the Benchy_Sump_LogicAnalyzer_Standalone example? Here I am a bit confused by 2 things: Here the markers used are called "rxd" and "txd". How are they related to "RXD" "TXD"? This boils down to the question of what serial port gets used?The code does no serial forwarding. Again what serial port is used? The FPGA one? For me this one is occupied by ZPUino, right?Thanks a lot!
  5. Hello Jack! What's the plan about a release of a linux solution for the JTAG server and Logic Analyzer client software? What is "Coming soon"? I had a look for linux JTAG servers, I found; Altera and UrJTAG (last update 2009) - so I don't know what to do here right now. I tried to use the RXD and TXD markers, like: which resulted in 2 mapping errors: ERROR:Pack:2811 - Directed packing was unable to obey the user design constraints (LOC=P46) which requires the combination of the symbols listed below to be packed into a single IOB component. The directed pack was not possible because: More than one pad symbol. The symbols involved are: BUF symbol "RXD_IBUF" (Output Signal = RXD_IBUF) PAD symbol "RXD" (Pad Signal = RXD) PAD symbol "ext_pins_in<2>" (Pad Signal = ext_pins_in<2>) ERROR:Pack:2811 - Directed packing was unable to obey the user design constraints (LOC=P141) which requires the combination of the symbols listed below to be packed into a single IOB component. The directed pack was not possible because: More than one pad symbol. The symbols involved are: BUF symbol "TXD_OBUF" (Output Signal = TXD) PAD symbol "TXD" (Pad Signal = TXD) PAD symbol "ext_pins_out<25>" (Pad Signal = ext_pins_out<25>) so I went for the Arduino pin markers as: which synthesized well. Next I will run a sketch like the Arduino Mega serial example code (very similar to the Benchy_Sump_LogicAnalyzer sketch) in order to forward the serial data as mentioned. Will keep you informed... Thanks for your help and Greetings
  6. I had a short look and from that as well from what you describe, I think that is the solution to my question - I will test this as soon as possible! Thanks! Though just out of curiosity; would the solution I proposed before work as well? Good point; I'm running Linux. Parts of the reason why I love the Papilio DUO so much is it's Linux compatibility.
  7. Hello Jack Where do the RXD and TXD marker connect to? (Arduino_0 and Arduino_1? Did you change the COM port used in the example video?) I need to have a Logic Analyzer in my ds1wm design for testing and debugging. Thus I had a look at the Benchy_Sump_LogicAnalyzer example. It uses a COMM_zpuino_wb_UART to connect the logic analyzer to the zpuino together with some code that forwards the serial data to and from USB serial port. The problem is that I need the same USB connection (from zpuino) to print debug data to console/monitor. So the question is how to connect the logic analyzer to the ATmega Serial1 port (and use it's USB serial connection) instead? Is ATmega Serial1 fast enough? Is such a connection established by using RXD and TXD? What physical connection/pin do RXD and TXD utilize? Thanks and Greetings DrTrigon
  8. I was struggling quite a bit ... In my library folder are 2 projects; the ds1wm library and the wishbone variant. Basically I tried to change the .vhd file and regenerate the symbol of the first one which consists of 6 .vhd files. I was not able to do it since no matter what I tried, from removing 1 file to removing all in various ways - either ISE was not able to generate the new symbol or freezed. I was never able to get to the view shown here having the new .vhd file separate, respective not in the Edit_Your_Chip_Design category and thus could not properly (re)generate the symbol. The 'Code to the VHDL File', 'Turn the VHDL File into A Schematic Symbol' and 'Edit Design' parts turned out to be quite critical in the end. The only thing that helped in the end was compressing everything within the library folder into a archive and then delete it and start from an empty library folder. By doing so it worked and I was able to change my code as: [...] ENTITY ds1wm IS PORT ( ADDRESS : IN std_logic_vector(2 DOWNTO 0); ADS_bar : IN std_logic; CLK : IN std_logic; EN_bar : IN std_logic; MR : IN std_logic; RD_bar : IN std_logic; WR_bar : IN std_logic; INTR : OUT std_logic; STPZ : OUT std_logic; -- DATA : INOUT std_logic_vector(7 DOWNTO 0); DIN : IN std_logic_vector(7 downto 0); DOUT : OUT std_logic_vector(7 downto 0); DDIR : OUT std_logic; DQ : INOUT std_logic); END ENTITY ds1wm; [...] -- signal DDIR : std_logic; -- signal DOUT : std_logic_vector(7 downto 0); signal DQ_CONTROL : std_logic; -- signal DIN : std_logic_vector(7 downto 0); [...] xone_wire_io : one_wire_io PORT MAP ( CLK => CLK, -- DDIR => DDIR, DDIR => '0', -- DOUT => DOUT, DOUT => "00000000", DQ_CONTROL => DQ_CONTROL, MR => MR, -- DIN => DIN, DQ_IN => DQ_IN, -- DATA => DATA, DQ => DQ ); [...] So basically one_wire_io acts as an IOBUF that makes DATA from DIN, DOUT and DDIR. I disconnected this part of one_wire_io and feed the signals to pins instead. Yesss... I mean this is what I wanted to avoid in the first place... so I ended up doing it. BUT thanks to you I learned a lot on this journey. I do not really get this one... this code containing the if statement would be the same as an IOBUF as I tried to use it, right? Since bidirectional lines are not supported internally what I understand is that all codes always use DIN and DOUT internally and create the bidirectional only before connecting to a pin as a very last step, like the code I use does: DATA <= DOUT when DDIR='1' else "ZZZZZZZZ"; DIN <= DATA; So finally I was able to synthesize today and now step 3 doing the ZPUino code will follow! Thanks a lot for all support! Greetings and all the best! ds1wm_owmaster_Wishbone.pdf
  9. Hello Jack Yes, I somehow got suspicious about using bidirectional pins internally - and yes I learned it now "the hard way" and will never forget this again. As a friend of mine formulated it very nicely: "'Bidirectional' is a quick way to get a headache." )) He told me even when using on external pins there are restrictions. So lets rip the thing apart. (May be I should not write that I actually had a look a the datasheet of IOBUF, but I missed this part...) When thinking about it - using bidirectional internally must lead to shorting the chip as some point by accident. Thus I am actually quite happy that the software does refuse to generate such bitstreams. So my chip has 2 bidirectional pins - 1 is needed as the 1-wire bus is bidirectional, that's ok since it goes to an external pin. I had a look at the VHDL source and think its fairly straight forward to rip the bidirectional into 2 parts and separate in from out. I did it already. The issue I have is; I actually don't know how to re-generate the symbol from the changed code? Somehow I should be able to update the symbol or generate it newly, right? Can you lead me through? As long as there are no protection resistors available to insert on the schematic level, I think I am fine with changing the code now. Sure. Why? Thanks a lot and greetings
  10. Sure I connected 2 BiDirectional ports together, see marked part in the attached screenshot. The datasheet of the DS1WM Synthesizable 1-Wire Bus Master (IP core) is freely available, if needed. I'm not sure but I think I am allowed to reproduce the code (at least in parts) here as well, since the Acceptance letter states: The software source code DS1WM does not require a license and may be freely copied, modified or distributed without restriction. No act or omission by Maxim Integrated shall be deemed to constitute a representation or warranty by Maxim Integrated as to the functionality or utility of DS1WM. ...as English is not my native language I might be fooled but I think it should be safe, right?
  11. Now few minutes later I played around and learned a lot again; how to create Iterated Instances (array of instances on buses) for buffers like IOBUF, learned about the fact that dedicated buffers for in- and output exists (IBUF and OBUF), how to use BUF to separate/combine nets of different names, learned again some important lessions about how to use ISE, how to edit the symbol, etc. ... - a lot nice new stuff...! Was cool - thanks! So but when trying to synthesize the full blow example including ZPUino and correct/good CLK signal source etc. I ran into this: ERROR:Xst:528 - Multi-source in Unit <Papilio_DUO_LX9> on signal <XLXI_48/XLXI_2/DIN<7>>; this signal is connected to multiple drivers. Drivers are: Output port IOBUF:IO of instance <XLXI_48/XLXI_3_7> Output signal of BUFT instance <XLXI_48/XLXI_2/xone_wire_io/DATA<7>_DOUT<7>> ...this basically tells me what I intentionally did; I connected the INOUT port of my library (XLXI_2) to th IO port of an IOBUF (XLXI_3). What am I doing wrong? What am I missing? Greetings
  12. Hello Jack! I have to stick to a given 3rd-party code and don't want to change it right now. You are perfectly right. Sorry I should have mentioned initially that the symbol has read (RD) and write (WR) pins to select the data flow direction. I looked for BUFs but couldn't find any suitable ones. Now you are mentioning IOBUF and that was exactly what I was looking for! Thanks a lot! I'm away for experimenting now - will report back the results later... Goodbye and thanks for all the fish! ps.: The tutorial would be great anyway, just to see how you would do it - but for the moment I think I am fine.
  13. Indeed, directly got an impression of it; added the CLK marker connected to a BUFG connected to the CLK input of my symbol... error! ERROR:Place:1136: - This design contains a global buffer instance, <XLXI_62>, driving the net, <XLXN_1>, that is driving the following (first 30) non-clock load pins. < PIN: XLXI_61/xclk_prescaler/clk_1us1.A1; > This is not a recommended design practice in Spartan-6 due to limitations in the global routing that may cause excessive delay, skew or unroutable situations. It is recommended to only use a BUFG resource to drive clock loads. If you wish to override this recommendation, you may use the CLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demote this message to a WARNING and allow your design to continue. < PIN "XLXI_62.O" CLOCK_DEDICATED_ROUTE = FALSE; > ERROR:Pack:1654: - The timing-driven placement phase encountered an error. Ok, let's have a look; yes there is a xclk_prescaler.vhd but my symbol connects its CLK input to it, so since I have a BUFG there it should affect everything. On the other hand there is some effect since it is not the same error as in my initial post anymore (ERROR:Place:1108). Ok, next step; added the CLK marker connected to a papilio_clocks connected to the CLK input of my symbol... works! This is a miracle to me... To make it clear; Jack, I'm not surprised that your solution works but by the subtlety and complexety involved into this clock and bufg stuff... so ... thanks a lot for the papilio_clocks symbol!!! What would happen, if I would use the CLOCK_DEDICATED_ROUTE constraint mentioned? (Despite bad performance, of course.) No problem - actually I was positively surprised how well everything fits together and works hand-in-hand already. You for sure don't have to apologize for it! Currently I am working with DesignLab 1.0.7 in ubuntu and the only other flaw I came across was that the filename of the generated bitstream file has an issue with case sensitivity, e.g. "papilio_duo_lx9.bit" vs. "Papilio_DUO_LX9.bit". ISE uses capital letters where as DesignLab wants small ones only - I worked around it by creating symlinks called "papilio_duo_lx9.bit". Your advice opening the edit_library.ino worked perfectly. And now it's documented here as well - great! Greetings and Thanks
  14. To whom it may concern As mentioned in Map Errors due to IOB / BUFGMUX clock component not placed at an optimal site pair more precise in post #9, I am working to Make a Wishbone Library based on a symbol created before. Here I have the issue that I need to connect the "Wishbone_to_Registers_x10" to my symbol which has a data bus (8 bit) of pins defined as INOUT (BiDirectional), how to do that? I could think of a solution by using a bus multiplexer (switching 8 bit in parallel at the same time), which I couldn't find - actually not even single bit. Another idea was to do it in ZPUino software by switching Wishbone output registers to high impedance, but could not find any info about that. The hints I found so far were; change the source - what I don't want to do at this stage - this is kind of similar to what is done for the I2C implementations as explained in I2C on the Papilio One Zpuino Core - but I did not understand them or better how to use them for a 8 bit bus on the Papilio Duo. So ... any explanation or hint how to solve this issue is very welcome at this stage. Thanks a lot for your time and greetings
  15. Hello Jack As I understand the tutorial at that point, one creates an example circuit for the library, correct? Synthesizing is useful since if it does not at that stage, it won't later on when used as library either. May be I miss-understood the tutorial? This is a very extensive and useful lecture - thanks! I was not aware of the papilio_clocks symbol at all. Now ... ummm ... I really don't want to be a pain in the neck, BUT I am tempted to ask again; why it does not work with the marker? I had a look at papilio_clock and the only obvious difference I can spot is the use of BUFG to buffer all in- and outputs. Is that the magic that is supposed to solve my problem? I could not check on this, since I was not able to figure out how to open a library again (e.g. a second time) in DesignLab; the 'edit_library' tab, etc. are missing - can open the sketch only. Thanks a lot!