• Content count

  • Joined

  • Last visited

Everything posted by DrTrigon

  1. Sounds good. Can you elaborate a bit more and explain how I would practically have to do it? I do have basic experience with docker etc. but I have no idea how to modify a container properly...
  2. Hello I have really weird login issues for days now. Basically I cannot login to this forum and my account. Whenever I logout I have to reset my password in order to be able to login again. I even tried copy-n-paste my password from a text-editor, does not work either. I have thus to assume that my password does not get stored properly, may be it's a coding issue - honestly I have no clue... I need help here!! Thanks and Greetings
  3. I like the idea of having a VM to avoid all the install hassle. I finally setup a kubuntu 14.04 VM with DesignLab and ISE. I can offer that VM in case anyone wants it - however the license would have to be removed first. I ran your docker container as explained here and got cloud9 running. How can I run DesignLab and ISE? Is that possible?
  4. 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
  5. DrTrigon

    Wishbone version of the Sump Blaze Logic Analyzer

    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.
  6. 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
  7. ) 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!
  8. 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
  9. 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.
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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?
  15. 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
  16. 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.
  17. 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
  18. To whom it may concern First; thanks a lot for this amazing Papilio DUO thingy!!! This is what I was looking for since quite some time; a simple but still powerful and transparent approach to dive into FPGA, that does not hide or remove any part of the complexity but is equipped with tools to help you understand whats going on. Thanks and Congrats! I am very new to FPGA, my first project was to take "Multiple_Serial_Ports" and modify it slightly to make a 1-wire sniffer from it (basically it's 2 UARTs, one at 9600, one at 115200 listening on the same line with some ZPUino code). My second project now is to try to create a Library from Internet code! (from Make a Wishbone Library). Btw.: Thanks for the nice tutorials! Here my problem: I got some VHDL and Verilog code from a third-party source and everything worked out well until "Step 3 – Generate Programming File". Here I got several ERRORs that I could solve by changing some pins from "Arduino_28", "Arduino_34" and "Arduino_36" to "Arduino_8", "Arduino_11" and "Arduino_12". But the last ERROR is related to the "CLK" pin which I obviously cannot change, so here's the message: ERROR:Place:1108: - A clock IOB / BUFGMUX clock component pair have been found that are not placed at an optimal clock IOB / BUFGMUX site pair. The clock IOB component <CLK> is placed at site <P94>. The corresponding BUFG component <CLK_IBUF_BUFG> is placed at site <BUFGMUX_X3Y8>. There is only a select set of IOBs that can use the fast path to the Clocker buffer, and they are not being used. You may want to analyze why this problem exists and correct it. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message to a WARNING and allow your design to continue. However, the use of this override is highly discouraged as it may lead to very poor timing results. It is recommended that this error condition be corrected in the design. A list of all the COMP.PINs used in this clock placement rule is listed below. These examples can be used directly in the .ucf file to override this clock rule. < NET "CLK" CLOCK_DEDICATED_ROUTE = FALSE; > ERROR:Pack:1654: - The timing-driven placement phase encountered an error. So actually I have no idea what's going on here. But I came across VHDL newbie: 'if' on a process sensitivity list element where Jack mentioned: Looking at my Synthesis Report showed: [...] Synthesizing Unit <one_wire_interface>. [...] Found 1-bit register for signal <tbe_int>. Found 1-bit register for signal <EOWSH_int>. Found 1-bit register for signal <ersf_int>. Found 1-bit register for signal <erbf_int>. Found 1-bit register for signal <etmt_int>. Found 1-bit register for signal <etbe_int>. Found 1-bit register for signal <ias_int>. Found 1-bit register for signal <epd_int>. Found 1-bit register for signal <pre_0_int>. Found 1-bit register for signal <pre_1_int>. Found 1-bit register for signal <div_1_int>. Found 1-bit register for signal <div_2_int>. Found 1-bit register for signal <div_3_int>. Found 1-bit register for signal <CLK_EN_int>. Found 1-bit register for signal <FOW_int>. Found 1-bit register for signal <sr_a_int>. Found 1-bit register for signal <OD_int>. Found 1-bit register for signal <BIT_CTL_int>. Found 1-bit register for signal <STP_SPLY_int>. Found 1-bit register for signal <STPEN_int>. Found 1-bit register for signal <EN_FOW_int>. Found 1-bit register for signal <PPM_int>. Found 1-bit register for signal <LLM_int>. Found 1-bit register for signal <pd_int>. Found 1-bit register for signal <EOWL_int>. Found 8-bit register for signal <xmit_buffer>. Found 1-bit register for signal <owr_int>. Found 1-bit register for signal <clr_activate_intr_int>. Found 1-bit register for signal <xmit_buffer_full>. Found 8-bit 7-to-1 multiplexer for signal <DOUT> created at line 55. WARNING:Xst:737 - Found 1-bit latch for signal <sel_addr<2>>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems. WARNING:Xst:737 - Found 1-bit latch for signal <sel_addr<1>>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems. WARNING:Xst:737 - Found 1-bit latch for signal <sel_addr<0>>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems. Summary: inferred 36 D-type flip-flop(s). inferred 3 Latch(s). inferred 1 Multiplexer(s). Unit <one_wire_interface> synthesized. [...] Then looking at the VHDL code: [...] ---------------------------------------------------------------------------- -- Transparent address latch ---------------------------------------------------------------------------- process(ADS_bar,ADDRESS,EN_bar) begin if(((not ADS_bar) and (not EN_bar))='1') then sel_addr <= ADDRESS; end if; end process; [...] This was kind of irritating, since as it appears there is an address latch that was introduced on purpose. So what to do with that? How to convert this into registers? Would such a conversion make sense at all? (as I understand latches are asyncronous where registers are syncronous only, right?) The thing is, actually I have no clue whether this is related to my CLK issue this post is describing... To be honest I don't care about latches for now (it's only 3 bits, right? but I need to solve the CLK issue described in the beginning in order to be able to generate a programming file and proceed. Any hint is greatly appreciated. Thanks a lot for your time and greetings
  19. 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!
  20. Second step will be to Make a Wishbone Library for the zpuino, correct! But as I was still working at the first step to create a Library from Internet code! which involves adding a CLK in step 2 (Define Your Circuit) as can be seen from this scheme I was struggeling w/o having a zpuino yet. I was using the CLK from Utility.sch (on “Design” tab) as shown here, is there another one? This finally helped! Omitting the CLK solved the issue as I was am able to generate/synthesize the programming file now. The thing I am still puzzeling is; why the example from your tutorial contains adding a CLK ... or better; why does this not work in my example? What do you mean by "two methods" of connecting? I think, I might not get your point with the different clocks... can you explain this in more detail? As mentioned, the second step now is to Make a Wishbone Library based on this symbol. Here I have completely other issue described in How to connect Wishbone Registers to pins defined as INOUT (BiDirectional). Thanks a lot for your hints and greetings
  21. Hello Jack Thanks a lot for your answer (your product and work in general ! Thanks also for all the additional info you provided (e.g. about latch, etc.). Indeed this is the case! :-) I am setting up a library/symbol, so I am not that far yet (schematic is empty except for my part). Does this mean I should leave the CLK unconnected for now and connect it later while using the library in an ZPUino project? This is what I understood from johnbeetem's answer, too. Thanks for the clarification. Thanks and greetings (I might not be very resposive the next week - sorry)
  22. So generally speaking they are fine if introduced on purpose (and by somebody that knows what (s)he's doing . Ok, that's fine then, good. I did not have time to check the documents you suggested - will do this the next days. I just had another look to the reports; nothing special in Translation or Map Report but found this in the Synthesis Report: [...] Clock Information: ------------------ --------------------------------------------------+---------------------------------------------+-------+ Clock Signal | Clock buffer(FF name) | Load | --------------------------------------------------+---------------------------------------------+-------+ CLK | IBUF+BUFG | 13 | Arduino_12 | IBUF+BUFG | 33 | Arduino_11 | IBUF+BUFG | 1 | XLXI_61/clk_1us(XLXI_61/xclk_prescaler/clk_1us1:O)| BUFG(*)(XLXI_61/xone_wire_interface/tbe_int)| 96 | Arduino_8 | BUFGP | 3 | XLXI_61/xonewiremaster/rbf_set | NONE(XLXI_61/xonewiremaster/rbf_int) | 1 | --------------------------------------------------+---------------------------------------------+-------+ (*) This 1 clock signal(s) are generated by combinatorial logic, and XST is not able to identify which are the primary clock signals. Please use the CLOCK_SIGNAL constraint to specify the clock signal(s) generated by combinatorial logic. INFO:Xst:2169 - HDL ADVISOR - Some clock signals were not automatically buffered by XST with BUFG/BUFR resources. Please use the buffer_type constraint in order to insert these buffers to the clock signals to help prevent skew problems. [...] Is this useful? How to use the buffer_type contraint? Thanks and greetings!