urbite

Members
  • Content count

    15
  • Joined

  • Last visited

Community Reputation

0 Neutral

About urbite

  • Rank
    Member

Profile Information

  • Gender Male
  1. I was able to successfully rebuild papilio-prog.exe for Windows yesterday and used it to program the bootloader from the ZAP IDE. In the log window I could see a message indicating that the verification was successful, which indicates that the M25P40 SPI flash can be successfully programmed. I only tried it once, but could try to program it multiple times tonight and see if it programs consistently. In that case, the SPI programming would be validated. Alvie - which file in the bootloader has the code to support the various SPI flash families? I found the following file that appears to be the correct one in: https://github.com/GadgetFactory/Papilio-Loader/blob/master/xc3sprog/trunk/progalgspiflash.cpp It looks like the Numonyx/Micron vendor ID, 0x20, is in the search list: line 523: switch (fbuf[0]) { case 0x1f: res = spi_flashinfo_at45(fbuf); break; case 0x30: res = spi_flashinfo_amic(fbuf); break; case 0x40: res = spi_flashinfo_amic_quad(fbuf); break; case 0x20: res = spi_flashinfo_m25p(fbuf); break; And the 4 Mbit chip is in the sub-family list: line 362: switch (fbuf[1]) { case 0x20: fprintf(stderr, "Found Numonyx M25P Device, Device ID 0x%02x%02x\n", fbuf[1], fbuf[2]); switch (fbuf[2]) { case 0x11: pages = 512; sector_size = 32768; /* Bytes = 262144 bits*/ break; case 0x12: pages = 1024; break; case 0x13: pages = 2048; break; case 0x14: pages = 4096; break; case 0x15: pages = 8192; break; case 0x16: pages = 16384; break; If this is the file that's included in the XC3S bootloader, then it has the needed support and it's puzzling why it doesn't work. Alvie - I seem to remember have a similar experience getting the correct ID with the SPI flash when porting ZPU to the Nexsys 2 board. I'll put my Bus Pirate analyzer on the SPI lines tonight and see of the correct ID is being returned. Getting this to work isn't critical, as this particular Papilio One can simply be retired or replaced. Instead, now it's bugging me why it isn't working. If you can just point me to the relevant files and any needed general instructions, I'll do the rebuilding of the bootloader and testing on my end and report the results here.
  2. Thanks for finding this! It was the only thing stopping me from building a Windows version of the programmer on a Lubuntu VM.
  3. The code snippet I provided had a syntax errors - nested if-elses usually get me. I'll email you the corrected file that allows the programmer to build correctly. I tried to push the file to the repo, but it wasn't being allowed. This is my first time working with git, so I probably overlooked something obvious. Agreed on resuming tomorrow. I have to call it a night also. Thanks for your help and feedback. I'll send you a message per your request.
  4. #72 - I guess that makes me an early adopter :-) I *believe* I now have an executable that will program the bootloader bit file into the memory, and that I've been able to successfully do this. What I haven't been able to find are the source files that make up the bootloader, as it appears that the code the writes the sketch into the SPI flash doesn't support M25PXX parts. Either that or something else is not quite right. The only other reference I found to SPI programming was this file: https://github.com/GadgetFactory/Papilio-Loader/blob/master/xc3sprog/trunk/progalgspiflash.cpp However, it has support for the M25PXX parts, so if this is what's in the bootloader, then the 'Unknown flash type, exiting' error when attempting to program a sketch is puzzling. Can you point me to the source files that make up the actual bootloader?
  5. I just went through my emails and found some correspondence dated August 13, 2010, related to the purchase of this board this order from gadgetfactory. I forwarded the email to the support@gadgetfactory.net email address from whence the original email was received. Let me know if that's not a good email address. The order number was 72. While I understand that you don't want to help counterfeiters, it doesn't appear that this is a counterfeit board (based upon email correspondence and my memory). I think it's a good idea to have support for as many SPI flash devices as reasonably possible. The added space is minimal to support the additional family. I do know that this is a popular SPI flash family, as I've used them in several designs.
  6. I made the changes to progalgspi.cpp that were given in an earlier post. Thanks to the excellent readme file and a prebuilt Lubuntu 12.04 VM, I was able to check out the project, make the changes, and build a new papilio-prog.exe. There was one bump in the road where the build failed because of a syntax error involving PKG_CHECK_MODULES. A google search revealed the answer in - of all places - a gadgetfactory forum: http://forum.gadgetfactory.net/index.php?/topic/1195-papilio-loader-in-64-bit-linux/page-2#entry7056 Apparently some package was missing, as indicated by the following snippet from the referenced forum topic. As a linux hack, I never would have found this... ... Turns out I was missing the package pkg-config, so there was no PKG_CHECK_MODULES macro in aclocal.m4 as you suspected. ... Now I can burn a bootloader (or any other bit file) into my Papilio One board. After burning the bootloader I attempted to load the sample sketch. Unfortunately the attempt to load was met with the following error. Executing C:\projects\Papilio\loader\zap-2.0.7/hardware/tools/zpu/bin/zpu-elf-size C:\Users\PAULUR~1\AppData\Local\Temp\build324513325183267400.tmp/Papilio_QuickStart.cpp.elf Binary sketch size: 1,856 bytes (of a 12,160 byte maximum) - 1,836 bytes ROM, 236 bytes memory, 15% used Board: GadgetFactory Papilio One 250 @ 96000000 Hz (0xa4020e00) Unknown flash type, exiting The above error indicates that the lack of support for M25PXX SPI proms in the papilio programmer is also lacking in the bootloader, since I suspect the same or similar SPI functions are used. M25PXX support will need to be added to the bootloader before sketches can be successfully downloaded to this Papilio board. Should I push the modified progalgspi.cpp to the repository?
  7. I'm a bit puzzled why the SPI flash on my Papilio One is not supported by the loader. I assume that I have a very old board and the M25P series wasn't used on very many Papilio Ones, otherwise this issue would have likely been reported already.
  8. As detailed in post http://forum.gadgetfactory.net/index.php?/topic/1651-introducing-zap-ide-zpuino-and-avr8-together-at-last/page-2#entry12535, I've been unable to program the ZPUino bootloader into my Papilio One SPI flash. I've also tried with the standalone loader, which fails with the same error as the ZAP IDE. Here's the relevant info from the log window(s): JTAG chainpos: 0 Device IDCODE = 0x11c1a093 Desc: XC3S250E Using built-in device list ISC_Done = 1 ISC_Enabled = 0 House Cleaning = 1 DONE = 1 Programming to SPI Flash Using devlist.txt Programming a Papilio One 250K JTAG chainpos: 0 Device IDCODE = 0x11c1a093 Desc: XC3S250E Using devlist.txt Uploading "bscan_spi_xc3s250e.bit". Done. Programming time 111.0 ms Programming External Flash Memory with "C:\projects\Papilio\loader\zap-2.0.7/hardware/zpuino/zpu/bootloaders/p1_250k/zpuino-1.0-PapilioOne-S3E250-Vanilla-1.0.bit". Unknown Numonyx/Micron Flash Type (0x20) Error: SPI Status Register [0x00] mismatch (Wrong device or device not ready).. The last two lines indicate that an unrecognizable flash type was detected. The SPI flash on my board is an SST M25P40VP. After digging a bit more it appears that the M25XX family of SPI flash devices isn't supported in the loader. Although the flash is marked as an SST, it falls in the Numonyx/Micron category because SST was one of the partners that formed Numonyx. The manufacturer ID for the M25XX parts is 0x20, which is the same as Numonyx/Micron in the loader code. The only Numonxy/Micron parts supported are the newer N25XX family, which have a memory type = 0xBA while the M25xx parts have a memory type = 0x20. Hence, the above error makes sense. The loader source file where the SPI flash types are defined is progalgspi.cpp at https://github.com/GadgetFactory/Papilio-Loader/blob/master/papilio-prog/progalgspi.cpp Here is the relevant section of code. case 0x20: /* Numonyx/Micron */ if (tdo[2] == 0xBA) { //N25QXXX switch(tdo[3]) { case 0x16: /* N25Q32 */ Pages=16384; PageSize=256; BulkErase=60; SectorErase=3; FlashType=GENERIC; break; case 0x17: /* N25Q64 */ Pages=32768; PageSize=256; BulkErase=250; SectorErase=3; FlashType=GENERIC; break; case 0x18: /* N25Q128 */ Pages=65536; PageSize=256; BulkErase=250; SectorErase=3; FlashType=GENERIC; break; case 0x19: /* N25Q256 */ Pages=131072; PageSize=256; BulkErase=480; SectorErase=3; FlashType=GENERIC; break; default: printf("Unknown Numonyx/Micron N25Q Flash Size (0x%.2x)\n", tdo[3]); return false; } if(verbose) printf("Found Numonyx/Micron Flash (Pages=%d, Page Size=%d bytes, %d bits).\n",Pages,PageSize,Pages*PageSize*8); break; } else { printf("Unknown Numonyx/Micron Flash Type (0x%.2x)\n", tdo[2]); return false; } break; To support the M25XX family, the above bolded/colorized code section should be changed to: } else { if (tdo[2] == 0x20) { //M25XX switch(tdo[3]) { case 0x11: /* M25P10A 1-Mbit*/ Pages=512; PageSize=256; BulkErase=6000; SectorErase=3000; FlashType=GENERIC; break; case 0x12: /* M25P20 2-Mbit*/ Pages=1024; PageSize=256; BulkErase=6000; SectorErase=3000; FlashType=GENERIC; break; case 0x13: /* M25P40 4-Mbit*/ Pages=2048; PageSize=256; BulkErase=10000; SectorErase=3000; FlashType=GENERIC; break; case 0x14: /* M25P80 8-Mbit */ Pages=4096; PageSize=256; BulkErase=20000; SectorErase=3000; FlashType=GENERIC; break; case 0x15: /* M25P16 16-Mbit */ Pages=8192; PageSize=256; BulkErase=40000; SectorErase=3000; FlashType=GENERIC; break; case 0x16: /* M25P32 32-Mbit */ Pages=16384; PageSize=256; BulkErase=80000; SectorErase=3000; FlashType=GENERIC; break; default: printf("Unknown Numonyx/Micron M25P Flash Size (0x%.2x)\n", tdo[3]); return false; } if(verbose) printf("Found Numonyx/Micron Flash (Pages=%d, Page Size=%d bytes, %d bits).\n",Pages,PageSize,Pages*PageSize*8); break; } else { printf("Unknown Numonyx/Micron Flash Type (0x%.2x)\n", tdo[2]); return false; } break; Is there anyone who'll volunteer to rebuild the loader for windows with the above changes? I'm primarily an mswindows guy and just enough of a linux person to get bogged down in rebuilding, whereas an expert could do it rather quickly. After the loader is rebuilt can I simply replace papilio-prog.exe in my ZAP IDE at <somewhere>\zap-2.0.7\hardware\tools\papilio\papilio_loader\bin\? Or do I need to replace more files?
  9. A bit more detective work reveals something quite puzzling. As a reference, my Papilio One serial ports enumerate as COM23 and COM24. Based upon the ZAP instructions (at http://www.papilio.cc/index.php?n=Papilio.ZAPIDE#Section3), FTDI serial port B should enumerate as the second port (COM24) but instead it enumerates as COM23. I loaded the Papilio_QuickStart sketch then started up TeraTerm and tried COM24 but no joy. However, when I switched to COM23 I can now see the ASCII chart being written. If I select COM23 in the Arduino ZAP IDE - it works also!!! After shutting down and restarting the Arduino AZP IDE, I can see the ASCII chart when the IDE is configured with COM23 (the lower numbered) serial port. Any ideas on why these are swapped? Or is this just a documentation issue?
  10. Using an oscilloscope, I can confirm that the sketch is running. To do this I made the following changes to the Papilio_QuickStart sketch. 1. Commented out the if statement that looks at the button pins to determine if the LED blinks or is driven on. This was done because I have only the Papilio One board with no wings and I if there are pullups enabled on the FPGA pins then the LED pins will be statically driven high. I wanted to see the toggle on the pins. Result: LED pins toggle every 250 ms. 2. Changed the delay between LED toggles in the main loop from 200 ms to 1 ms. Result: LED pins toggle every 45-48 ms. This tells me that the serial I/O is taking 44-47 ms. One byte from the ASCII chart is sent out of the serial port every LED toggle, and there are 26 characters sent out of the serial port for each ASCII byte. At 9600 baud that is approximately 1 char/ms = 26 ms, leaving approximately 20 ms for string conversions and loop overhead. 3. Changed the baud rate from 9600 baud to 19200 Result: LED pins toggle every 25 ms. To first order this makes sense as the toggle time has been reduced by 20 mS and doubling the serial transmission speed accounts for 13 ms of the reduced toggle time. After looking at the Papilio One schematic an probing further, the serial output from FPGA is visible on FPGA pin 90 and FTDI pin 39 on net USB_RXD. Based on this net name, one has to assume that the serial direction reference is the PC instead of the Papilio. Does this mean I need new FTDI drivers? They are working enough to allow the JTAG loading over the first FTDI serial port.
  11. I have a Papilio One 250 which I'm trying to use with ZAP 2.0.7. I've followed the direction at ZAP IDE Getting Started Guide - ZPUino section and have had partial success. When attempting to program the bootloader I can see that the SPI programmer bit file is successfully downloaded. However, after that the ZAP IDE gives a message that the SPI prom type is not recognized. When I look at the SPI flash chip it appears to be an ST Micro 25P40VP. The board rev info is: Papilio Platform Papilio One www.GadgetFactory.net USB FPGA REDe BPC3003 V2.04 250K silkscreen square is marked with permanent marker (and matches FPGA marking) The info from the log window is pasted below. JTAG chainpos: 0 Device IDCODE = 0x11c1a093 Desc: XC3S250E Using built-in device list ISC_Done = 1 ISC_Enabled = 0 House Cleaning = 1 DONE = 1 Programming to SPI Flash Using devlist.txt Programming a Papilio One 250K JTAG chainpos: 0 Device IDCODE = 0x11c1a093 Desc: XC3S250E Using devlist.txt Uploading "bscan_spi_xc3s250e.bit". Done. Programming time 111.5 ms Programming External Flash Memory with "C:\projects\Papilio\loader\zap-2.0.7/hardware/zpuino/zpu/bootloaders/p1_250k/zpuino-1.0-PapilioOne-S3E250-Vanilla-1.0.bit". Unknown Numonyx/Micron Flash Type (0x20) Error: SPI Status Register [0x00] mismatch (Wrong device or device not ready).. Error occured. USB transactions: Write 44 read 8 retries 0 JTAG chainpos: 0 Device IDCODE = 0x11c1a093 Desc: XC3S250E Using devlist.txt ISC_Done = 1 ISC_Enabled = 0 House Cleaning = 1 DONE = 1 processing.app.debug.RunnerException: the selected serial port DONE = 1 does not exist or your board is not connected at processing.app.debug.BasicUploader.burnBootloader(BasicUploader.java:321) at processing.app.Editor$47.run(Editor.java:2540) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) at java.awt.EventQueue.dispatchEvent(EventQueue.java:597) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) Another issue: I was able to successfully compile and load the Papilio_QuickStart sketch to the Papilio One 250K "Shifty AVR8" board without errors. However, I don't see the ASCII chart echoed to the Arduino serial port monitor. I can see the Papilio One RX LED blinking, but the TX LED never has any activity. I would expect the TX light to blink when the ASCII chart is sent out the serial port. Here's the log window when attempting the AVR8 load. Executing C:\projects\Papilio\loader\zap-2.0.7\hardware\tools\avr\bin\avr-size -A C:\Users\PAULUR~1\AppData\Local\Temp\build2428522038982300145.tmp/Papilio_QuickStart.cpp.hex Binary sketch size: 3,076 bytes (of a 16,384 byte maximum) - 18% used make: Entering directory `C:/Users/PAULUR~1/AppData/Local/Temp/build2428522038982300145.tmp' Converting Intel hex file to Verilog Mem format: ./srec_cat Papilio_QuickStart.cpp.hex -Intel -Byte_Swap 2 -Data_Only -o tmp.mem -vmem 8 ./gawk ' BEGIN{FS=" ";} { $1= ""; print}' tmp.mem > out.mem Converting Intel hex file to Verilog Mem format: ./srec_cat Papilio_QuickStart.cpp.hex -Intel -Byte_Swap 2 -Data_Only -o tmp.mem -vmem 8 ./gawk ' BEGIN{FS=" ";} { $1= ""; print}' tmp.mem > out.mem Selecting Papilio One Bit file. Merging Verilog Mem file with Xilinx bitstream: ./data2mem -bm bitstreams/AVR8_PapilioOne_bd.bmm -bt bitstreams/AVR8_PapilioOne.bit -bd out.mem -o b out.bit #./data2mem -bm bitstreams/AVR8_PapilioOne_bd.bmm -bt out.bit -d > out.dmp Writing Bit file to the Hardware ./papilio-prog -v -f out.bit -v JTAG chainpos: 0 Device IDCODE = 0x11c1a093 Desc: XC3S250E Using devlist.txt Created from NCD file: top_avr_core_v8.ncd;UserID=0xFFFFFFFF Target device: 3s250evq100 Created: 2010/10/15 12:59:05 Bitstream length: 1353728 bits Uploading "out.bit". Done. Programming time 268.0 ms USB transactions: Write 90 read 6 retries 0 make: Leaving directory `C:/Users/PAULUR~1/AppData/Local/Temp/build2428522038982300145.tmp'
  12. Here's a blog post on the difference between the rising_edge() function and (foo'edge and foo='1'). Of course you've already found the root cause of the problem, but thought you might like this for reference. On thing that was pointed out in some followup comments is that rising_edge() will fail if the edge sensitive signal is created by a pullup or pulldown and open drain driver. You wouldn't be simulating this in an FPGA - long lines ant TBUFs are long gone from FPGAs. But if you were using ISIM to do a sim of some legacy board level logic, this might be an issue. http://vhdlguru.blogspot.com/2010/04/difference-between-risingedgeclk-and.html
  13. Alex, I didn't expect my initial simulation of your code to yield such a strange result either. It's hard to imagine that a funciton expecting a scalar argument would handle a bit from a vector differently (and incorrectly!). Apparently a vector of length 1 isn't the same as a scalar signal??? OK, now on to the important stuff. 1. How can I include inline images in my post, as you did, without saving them externally and providing a url? Do I have to reach a minimum post count first? 2. What code format did you use to get decent colorization? As you can see, the colorization in my code snippet gets out of sync at times.
  14. OK, so I made a few code mods and ran some tests. What I found is that the rising_edge() function in ISIM doesn't appear to work correctly when the argument is a bit in a standard_logic_vector (or maybe for any vector, as I didn't try bit_vector). I added four new processes, each slight modifications to the original to see which would detect the rising edge of counter(1). I also added a boolean signal, counter_1_re_x, that replicates the counter(1) trigger expressions in each of the 5 processes. The activity of these boolean signals gives a direct indicator of whether the process where the corresponding expressions are used will be triggered when desired. Here's what I found. Original 'output' is always 0, which is the original problem. Signal 'counter_1_re_orig' only toggles when counter(4) is low??? Thus the output is consistent with this behavior. Parentheses This test just wrapped 'counter(1)' in parentheses inside of the rising_edge() function call. The thought was to have the bit fully 'evaluated' before the function call was made. It was really just a stab in the dark, since this is such an odd problem. 'output_parens' is always 0, which was expected. The boolean signal, 'counter_1_re_parens' has the same behavior as 'counter_1_re_orig'. Alias This test aliased 'counter(1)' to 'counter_1_alias'. 'counter_1_alias' replaces 'counter(1) in the process sensitivity list and in the rising_edge('counter_1_alias') function call. As with the parentheses, the thought was to have the bit fully 'evaluated' before the function all was made. Another stab in the dark, since this is such an odd problem. 'output_alias' is always 0. The boolean signal, 'counter_1_re_alias' has slightly different behavior from 'counter_1_re_orig', which is odd. It's hard to describe, so you'll have to run the sim until I figure out how to add images in a post. Assign This test assigned 'counter(1)' to 'counter_1_assign', 'counter_1_alias' replaces 'counter(1) in the process sensitivity list and in the rising_edge('counter_1_alias') function call. My suspicion was that form some reason the rising_edge() function has a bug when the passed parameter is part of a vector. 'output_assign' is correct!!! The boolean signal, counter_1_re_assign' <= rising_edge(counter_1_assign), changes on every edge of 'counter(1)' as expected. It is true when counter(1) is high and false when it is low. Classic This test uses the classic elsif counter(1)'event and counter(1)='1' then in the process instead of using the rising_edge() function call. 'output_classic' is correct!!! The boolean signal, counter_1_re_assign' <= rising_edge(counter_1_assign), has the same behavior as the Assign test described previously. There appears to be something amiss with the rising_edge() function in the Xilinx library or the way in which ISIM evaluates the function. In either case it seems to be quite a serious error. I ran the simulation using ModelSim 10.1 and all 5 test cases have the same (and correct!) output values. I grudgingly pay the annual maintenance cost for ModelSim each year because I rely heavily on simulations for my customer's projects. ModelSim is the standard for HDL simulators and it delivers for me. I realize that for many on this forum ModelSim isn't an economically viable option. I do know that Xilinx' internal IP development team uses ModelSim to validate their designs, not ISIM - and that says a lot. If you will be using ISIM to validate your design, it appears you'll have to modify the code to change all rising_edge() and falling_edge() function instances to foo'event and foo = '1' (or '0'). That shouldn't be too difficult and isn't a bad price to pay for a free mixed mode simulator. Another option would be to use an open source simulator such as GHDL. I don't have any experience with this tool, but I've read good things about it. library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all;entity test_tb isend test_tb;architecture behavior of test_tb is signal output : std_logic := '0'; signal counter : std_logic_vector(4 downto 0) := (others => '0'); constant period : time := 20 ns; -- add stuff to test rising_edge() function signal output_parens : std_logic := '0'; signal output_alias : std_logic := '0'; signal output_assign : std_logic := '0'; signal output_classic : std_logic := '0'; alias counter_1_alias : std_logic is counter(1); signal counter_1_assign : std_logic; signal counter_1_re_orig : boolean := false; signal counter_1_re_alias : boolean := false; signal counter_1_re_parens : boolean := false; signal counter_1_re_classic : boolean := false; signal counter_1_re_assign : boolean := false;begin process begin wait for period; counter <= counter + 1; end process; process(counter(1), counter(4)) begin if (counter(4) = '0') then output <= '0'; elsif rising_edge(counter(1)) then output <= (not counter(3)) and counter(2); end if; end process; -- wrap counter(1) in parentheses to insure -- it is evaluated and doesn't remain part of a vector p_counter_1_re_parens: process(counter(1), counter(4)) begin if (counter(4) = '0') then output_parens <= '0'; elsif rising_edge((counter(1))) then output_parens <= (not counter(3)) and counter(2); end if; end process p_counter_1_re_parens; -- use alias to counter(1) so that a part -- of a vector isn't passed to rising_edge() p_counter_1_re_alias: process(counter_1_alias, counter(4)) begin if (counter(4) = '0') then output_alias <= '0'; elsif rising_edge(counter_1_alias) then output_alias <= (not counter(3)) and counter(2); end if; end process p_counter_1_re_alias; -- assign counter(1) to separate signal so -- it is no longer a part of a vector p_counter_1_re_assign: process(counter_1_assign, counter(4)) begin if (counter(4) = '0') then output_assign <= '0'; elsif rising_edge(counter_1_assign) then output_assign <= (not counter(3)) and counter(2); end if; end process p_counter_1_re_assign; -- use the classic 'longhand' rising edge test -- instead of the rising_edge() function p_counter_1_re_classic: process(counter(1), counter(4)) begin if (counter(4) = '0') then output_classic <= '0'; elsif counter(1)'event and counter(1)='1' then output_classic <= (not counter(3)) and counter(2); end if; end process p_counter_1_re_classic; -- test all of the rising edge methods counter_1_assign <= counter(1); counter_1_re_orig <= rising_edge(counter(1)); counter_1_re_parens <= rising_edge((counter(1))); counter_1_re_alias <= rising_edge(counter_1_alias); counter_1_re_assign <= rising_edge(counter_1_assign); counter_1_re_classic <= true when counter(1)'event and counter(1)='1' else false;end;
  15. Alex - I just ran your code in ISIM 13.3 and I get the same result: output is always 0. When I single step through the 2nd process, here's what I observe: 1. The process is being triggered as expected when either counter(1) or counter(4) changes 2. Oddly, the elsif rising_edge(counter(1)) then conditional test is NEVER reached when counter(4) = '1'. That is, the process is suspended immediately after the failed if (counter(4) = '0') then conditional test??? I simulated your testbench using ModelSim PE 10.1 and the simulation works as you expected, as shown below. Well, I tried to post the image but got a popup that said "You are not allowed to use that image extension on this community." I pasted the screen clip from Windows clipboard. How do I post images in a reply as you did?