here's the pinout of a board I'm using: # chipset: # xc3s500e-4cp132 # # 3s500E # xxxxx-xxxx # korea # C6-DGQ 4C # # apparently the c6 defines the packages as CPG132 as per # xilinx document ds312.pdf # 1 --|DGND 5V IN |-- 40 # 2 --|DGND DGND |-- 39 # 3 --|PIN3 dual PIN38 |-- 38 dual/gclk # 4 --|PIN4 dual PIN37 |-- 37 dual # 5 --|PIN5 rhclk/dual PIN36 |-- 36 I/O # 6 --|PIN6 rhclk/dual PIN35 |-- 35 dual/gclk # 7 --|PIN7 rhclk/dual PIN34 |-- 34 lhclk # 8 --|PIN8 rhclk/dual PIN33 |-- 33 lhclk # 9 --|PIN9 rhclk/dual PIN32 |-- 32 I/O # 10 --|PIN10 I/0 PIN31 |-- 31 lhclk # 11 --|PIN11 dual PIN30 |-- 30 I/O # 12 --|PIN12 dual PIN29 |-- 29 lhclk # 13 --|PIN13 lhclk PIN28 |-- 28 lhclk # 14 --|PIN14 rhclk/dual PIN27 |-- 27 I/O # 15 --|PIN15 dual PIN26 |-- 26 I/O # 16 --|PIN16 gclk PIN25 |-- 25 I/O # 17 --|PIN17 gclk PIN24 |-- 24 vref # 18 --|PIN18 lhclk PIN23 |-- 23 I/O # 19 --|DGND DGND |-- 22 # 20 --|DGND DGND |-- 21 I checked against the Xilinx documentation for the type associated with the pins so I mapped them out using xilinx ds312.pdf and came up with this type configuration for CP132 Ball. It seems what I put out on the output pins is relevant. Pin15 has a 1/4 second blink code, while pins 17 and 18 have a 2mhz signal going out and all is OK. If I swap pins 15 and 18, I lock up. IF I drive Pin 13 with the 2mhz signal, no problem also. Simply put, if I drive PIN13 or PIN18 (the lhclk types) at 2mhz, no problem, but if I drive them at 4hz, they lock up the fpga. Any insight or suggested reading/ places to look in the multitude of summary reports that ISE generates? I found it strange that nothing strange appears in the build process or in testbench, but when I download the program, the FPGA locks up and only a power down and up resets it.
fpga locks up with slow signal, spartan chip, pin type issues.
Started by ●April 17, 2009
Reply by ●April 17, 20092009-04-17
On Apr 17, 10:55 am, jleslie48 <j...@jonathanleslie.com> wrote:> here's the pinout of a board I'm using: > > # chipset: > # xc3s500e-4cp132 > # > # 3s500E > # xxxxx-xxxx > # korea > # C6-DGQ 4C > # > # apparently the c6 defines the packages as CPG132 as per > # xilinx document ds312.pdf > > # 1 --|DGND 5V IN |-- 40 > # 2 --|DGND DGND |-- 39 > # 3 --|PIN3 dual PIN38 |-- 38 dual/gclk > # 4 --|PIN4 dual PIN37 |-- 37 dual > # 5 --|PIN5 rhclk/dual PIN36 |-- 36 I/O > # 6 --|PIN6 rhclk/dual PIN35 |-- 35 dual/gclk > # 7 --|PIN7 rhclk/dual PIN34 |-- 34 lhclk > # 8 --|PIN8 rhclk/dual PIN33 |-- 33 lhclk > # 9 --|PIN9 rhclk/dual PIN32 |-- 32 I/O > # 10 --|PIN10 I/0 PIN31 |-- 31 lhclk > # 11 --|PIN11 dual PIN30 |-- 30 I/O > # 12 --|PIN12 dual PIN29 |-- 29 lhclk > # 13 --|PIN13 lhclk PIN28 |-- 28 lhclk > # 14 --|PIN14 rhclk/dual PIN27 |-- 27 I/O > # 15 --|PIN15 dual PIN26 |-- 26 I/O > # 16 --|PIN16 gclk PIN25 |-- 25 I/O > # 17 --|PIN17 gclk PIN24 |-- 24 vref > # 18 --|PIN18 lhclk PIN23 |-- 23 I/O > # 19 --|DGND DGND |-- 22 > # 20 --|DGND DGND |-- 21 > > I checked against the Xilinx documentation for the type associated > with the pins so I mapped them out using xilinx ds312.pdf and came up > with this type configuration for CP132 Ball. > > It seems what I put out on the output pins is relevant. Pin15 has a > 1/4 second blink code, while pins 17 and 18 have a 2mhz signal going > out and all is OK. > If I swap pins 15 and 18, I lock up. IF I drive Pin 13 with the > 2mhz signal, no problem also. > > Simply put, if I drive PIN13 or PIN18 (the lhclk types) at 2mhz, no > problem, but if I drive them at 4hz, they lock up the fpga. > > Any insight or suggested reading/ places to look in the multitude of > summary reports that ISE generates? I found it strange that nothing > strange appears in the build process or in testbench, but when I > download the program, the FPGA locks up and only a power down and up > resets it.Ok, its not that simple. I've been messing with this all day. I can't find a pattern that is repeatable. Right now I'm driving PIN18 at 2mhz 50% duty cycle, and PIN 17 similiarly. If I so much as add PIN 15 to the UCF, the PORT layout, and simply tie the same std_logic wire that drives PIN18 to PIN15, the FPGA fails. I also checked the pin's types once more, I documented them wrong. it turns out PIN15 is not DUAL but rather I/O the layout of the pins is: # 1 --|DGND 5V IN |-- 40 # 2 --|DGND DGND |-- 39 # 3 --|PIN3 dual PIN38 |-- 38 dual/gclk # 4 --|PIN4 dual PIN37 |-- 37 dual # 5 --|PIN5 rhclk/dual PIN36 |-- 36 I/O # 6 --|PIN6 rhclk/dual PIN35 |-- 35 dual/gclk # 7 --|PIN7 rhclk/dual PIN34 |-- 34 lhclk # 8 --|PIN8 rhclk/dual PIN33 |-- 33 lhclk # 9 --|PIN9 rhclk/dual PIN32 |-- 32 I/O # 10 --|PIN10 I/0 PIN31 |-- 31 lhclk # 11 --|PIN11 dual PIN30 |-- 30 I/O # 12 --|PIN12 dual PIN29 |-- 29 lhclk # 13 --|PIN13 lhclk PIN28 |-- 28 lhclk # 14 --|PIN14 rhclk/dual PIN27 |-- 27 I/O # 15 --|PIN15 I/O PIN26 |-- 26 I/O # 16 --|PIN16 gclk PIN25 |-- 25 I/O # 17 --|PIN17 gclk PIN24 |-- 24 vref # 18 --|PIN18 lhclk PIN23 |-- 23 I/O # 19 --|DGND DGND |-- 22 # 20 --|DGND DGND |-- 21 It really got frustrating for a while, I added Pin13 for a stretch, and then deleted it but no matter what I did, The place and route report complained that PIN13 was unrouted. The pinout report also showed PIN13 in there. No amount of of re-run all fixed the problem. I made a new project, dragged copies of my sources over, and re-built the project, and that finally destroyed all references to the PIN13 However since then, Even if I try and drive pin 15 at 4hz, it fails. I don't know if I'm supposed to be changing some of the defaults in the build process, or if I need to update my ISE package. My ISE package is 10.1 and I also loaded service pack 3, but I know there are more patches to the software available. I just hate to load updates unless I know they are directly associated to some functionality I need.
Reply by ●April 18, 20092009-04-18
On Fri, 17 Apr 2009 15:29:24 -0700 (PDT), jleslie48 <jon@jonathanleslie.com> wrote:>On Apr 17, 10:55 am, jleslie48 <j...@jonathanleslie.com> wrote: >> here's the pinout of a board I'm using:>Ok, its not that simple. I've been messing with this all day. I >can't find a pattern >that is repeatable.>No amount of of re-run all fixed the problem. I made a new project, >dragged copies of my sources over, and re-built the project, and that >finally destroyed all references to the PIN13 However since then, >Even if I try and drive pin 15 at 4hz, it fails.There has to be something else going on... One question: where are you getting a 4Hz clock? Does it have a reasonable rise/fall time or such a slow ramp that the Xilinx input buffers are oscillating like crazy as it passes through the transition region? You might be better using a 100MHz clock and a 4Hz enable signal... - Brian
Reply by ●April 18, 20092009-04-18
On Apr 18, 6:44 am, Brian Drummond <brian_drumm...@btconnect.com> wrote:> On Fri, 17 Apr 2009 15:29:24 -0700 (PDT), jleslie48 <j...@jonathanleslie.com> > wrote: > > >On Apr 17, 10:55 am, jleslie48 <j...@jonathanleslie.com> wrote: > >> here's the pinout of a board I'm using: > >Ok, its not that simple. I've been messing with this all day. I > >can't find a pattern > >that is repeatable. > >No amount of of re-run all fixed the problem. I made a new project, > >dragged copies of my sources over, and re-built the project, and that > >finally destroyed all references to the PIN13 However since then, > >Even if I try and drive pin 15 at 4hz, it fails. > > There has to be something else going on... > > One question: where are you getting a 4Hz clock? > > Does it have a reasonable rise/fall time or such a slow ramp that the Xilinx > input buffers are oscillating like crazy as it passes through the transition > region? > > You might be better using a 100MHz clock and a 4Hz enable signal... > > - Brianthe system has a 40Mhz oscillator and I set a countdown counter to 10,000,000, subtract 1 every oscillator clock and at 0 I reset the counter to10,000,000 and: clk_4hz <= not clk_4hz; something like that, I don't have the exact code in front of me. bascially I use this as a heartbeat indicator for the FPGA, I use this heartbeat to drive an led so I know the program is running; I've been doing it for years on systems. I also will enhance the blink code occasionally to indicate software versons. This way if a field test engineer is having an issue, Over the phone I can have him check the blink pattern (ex dot,dot,dot, off, dot,dot,dot ...) and I can know if he has the right version of code or not by making sure that I change the blink code on each version of the code. Meantime, I wrote some code that worked great and put out my 2mhz signal just fine. I then tried to copy the blink code to a pin that is connected to a header so I put the blink code on the front panel of the project box, and all of a sudden I stuck on this ridiculous problem. GRRRRRR..... I also will need to duplicate the 2mhz signal to as many as 4 output pins, this kind of stuff should be a no-brainer but I must have some underlying issue of no-no's under the surface. I'm willing to bet the FPGA lockup on adding the pin connection is just because by adding that bit of logic things get moved around during the SIG (synthesis, implement, generate) just enough so that my mistake ends up causing a lock up. I did have the driver on pin15 at 1/4 second working at one time, but then I tried to add pin 13, it died, and then when I removed the logic for pin 13, pin 15 was broken as well. This ISE 10.1 is very buggy. I have a whole list of WTF??? and situations where I just crashed it. I've only installed service pack 3, and I know there are some other patches that go, but until someone says "oh yeah!!! I had that problem if you update ISE 10.1 with xyz then the problem is fixed!!!!" I'm reluctant to introduce the new variable of a software patch.
Reply by ●April 18, 20092009-04-18
On Sat, 18 Apr 2009 09:56:10 -0700 (PDT), jleslie48 <jon@jonathanleslie.com> wrote:>> One question: where are you getting a 4Hz clock?>> You might be better using a 100MHz clock and a 4Hz enable signal... >> >> - Brian > >the system has a 40Mhz oscillator and I set a countdown counter to >10,000,000, >subtract 1 every oscillator clock and >at 0 I reset the counter to10,000,000 and: > >clk_4hz <= not clk_4hz;OK so it's internally generated; rise times aren't the problem. But it may not be identified by the tools as a clock; and that can cause problems. Do the tools actually identify it as a clock signal? (Should appear in the Translate clock report, and in PAR and timing reports) One approach would be to generate an enable ( a pulse 1 clk40MHz cycle wide) from it (easy: e.g. delay it 1 cycle and XOR them for an 8Hz enable) and clock the actual logic off 40MHz. This will ensure the tool's timing analysis works correctly and eliminates a major potential set of problems; it may waste a few mw if that matters. Another approach would be to instantiate a BUFG on the 4Hz clock. Then the BUFG output should be automatically routed on low skew networks and analyzed for timing hazards.> >This ISE 10.1 is very buggy. I have a whole list of WTF??? and >situations where I just crashed it.Absolutely and you are correct to be wary of upgrading without good cause. I used ISE7.1 exclusively until changing to 10.1 last year. (10.1 is sufficiently better to be worth it though) But though the tools crash, and may not be able to handle a clock they can't identify, they are pretty solid at delivering reliable results when used within their limits; e.g. with either technique above. - Brian
Reply by ●April 18, 20092009-04-18
On Apr 18, 6:43 pm, Brian Drummond <brian_drumm...@btconnect.com> wrote:> On Sat, 18 Apr 2009 09:56:10 -0700 (PDT), jleslie48 <j...@jonathanleslie.com> > wrote: > > >> One question: where are you getting a 4Hz clock? > >> You might be better using a 100MHz clock and a 4Hz enable signal... > > >> - Brian > > >the system has a 40Mhz oscillator and I set a countdown counter to > >10,000,000, > >subtract 1 every oscillator clock and > >at 0 I reset the counter to10,000,000 and: > > >clk_4hz <= not clk_4hz; > > OK so it's internally generated; rise times aren't the problem. > But it may not be identified by the tools as a clock; and that can cause > problems. > > Do the tools actually identify it as a clock signal? (Should appear in the > Translate clock report, and in PAR and timing reports) > > One approach would be to generate an enable ( a pulse 1 clk40MHz cycle wide) > from it (easy: e.g. delay it 1 cycle and XOR them for an 8Hz enable) and clock > the actual logic off 40MHz. This will ensure the tool's timing analysis works > correctly and eliminates a major potential set of problems; it may waste a few > mw if that matters. > > Another approach would be to instantiate a BUFG on the 4Hz clock. Then the BUFG > output should be automatically routed on low skew networks and analyzed for > timing hazards. > > > > >This ISE 10.1 is very buggy. I have a whole list of WTF??? and > >situations where I just crashed it. > > Absolutely and you are correct to be wary of upgrading without good cause. I > used ISE7.1 exclusively until changing to 10.1 last year. (10.1 is sufficiently > better to be worth it though) > > But though the tools crash, and may not be able to handle a clock they can't > identify, they are pretty solid at delivering reliable results when used within > their limits; e.g. with either technique above. > > - BrianBrian, Thanks for the tips. they will be tried/looked at on monday morning. I am confused though. what's the big deal about it being a "clock"? All I'm doing is sending it out an output pin to blink an led, whats the deal with BUFG, etc? I don't care about mw or even if its delayed, its just a blinking led on the project box... I don't get why tying a std_logic value to a second output pin can be a catalyst to a catastrophic failure of an FPGA.
Reply by ●April 18, 20092009-04-18
On Apr 18, 6:43 pm, Brian Drummond <brian_drumm...@btconnect.com> wrote:> > But though the tools crash, and may not be able to handle a clock they can't > identify, they are pretty solid at delivering reliable results when used within > their limits; e.g. with either technique above. > > - Brianthis has me very scared. I know for a fact at one point I put in a pin13 and then removed it, but the build still had references to pin13 (the map failed and the pinout report showed pin13) It wasn't until a made a whole new project that I eliminated the reference to pin13. After I made my new project, I found out about the clean up thing under projects and my old project was able to then build, but at that point PIN15 was broken. The point is, I get different results based on previous compile situations and previous results of the software. this is really bad. It means I can't reliably make a burn image, or possibly have to make a new project for each SIG/ reboot the computer between builds (I also notice that even if I shutdown the software, task manager has plenty of ISE images still in the background)
Reply by ●April 19, 20092009-04-19
On Sat, 18 Apr 2009 16:03:33 -0700 (PDT), jleslie48 <jon@jonathanleslie.com> wrote:>> One approach would be to generate an enable ( a pulse 1 clk40MHz cycle wide) >> from it (easy: e.g. delay it 1 cycle and XOR them for an 8Hz enable) and clock >> the actual logic off 40MHz. This will ensure the tool's timing analysis works >> correctly and eliminates a major potential set of problems; it may waste a few >> mw if that matters. >> >> Another approach would be to instantiate a BUFG on the 4Hz clock. Then the BUFG >> output should be automatically routed on low skew networks and analyzed for >> timing hazards.>Thanks for the tips. they will be tried/looked at on monday morning. >I am confused though. what's the big deal about it being a "clock"?For all other signals, the tools basically only need to guarantee the routing is faster than the clock period (+/- small allowance for jitter, clock skew etc); which at 4Hz or even 40MHz is easy. For a clock, the tools must perform a much more rigorous analysis; it is equally bad for a clock signal to arrive too early as too late! I presume your 4Hz clock is driving a simple state machine to blink blink blink; pause; repeat. If the clock delay to each FF in that SM isn't tightly controlled, it will reach some FFs before their inputs change, and others after their inputs (output from FFs clocked earlier) change. Hence there is no predicting what the SM will do. And each routing pass will behave differently; by chance, some may even work!>I don't get why tying a std_logic value to a second output pin can be >a catalyst to a catastrophic failure of an FPGA.That can cause the routing to change significantly. Don't let it scare you - once you find the groove; avoiding dodgy design areas - the tools will deliver reliable results. It's not any worse than C's pointer arithmetic! Re: persistence of obsolete pins: how are you generating constraints (UCF files)? If you are using the ISE tools, it's worth checking the UCF file in a text editor; I just use the editor and forget the tools (which maddeningly force another synthesis pass first because I updated a comment somewhere) I also check the translate (.bld) report, the map (.mrp) report and the PAR (.par) report; if any of these stages fail, you CAN end up using obsolete files (at least from the command line) - Brian
Reply by ●April 19, 20092009-04-19
On Apr 19, 9:06 am, Brian Drummond <brian_drumm...@btconnect.com> wrote:> On Sat, 18 Apr 2009 16:03:33 -0700 (PDT), jleslie48 <j...@jonathanleslie.com> > wrote: > > >> One approach would be to generate an enable ( a pulse 1 clk40MHz cycle wide) > >> from it (easy: e.g. delay it 1 cycle and XOR them for an 8Hz enable) and clock > >> the actual logic off 40MHz. This will ensure the tool's timing analysis works > >> correctly and eliminates a major potential set of problems; it may waste a few > >> mw if that matters. > > >> Another approach would be to instantiate a BUFG on the 4Hz clock. Then the BUFG > >> output should be automatically routed on low skew networks and analyzed for > >> timing hazards. > >Thanks for the tips. they will be tried/looked at on monday morning. > >I am confused though. what's the big deal about it being a "clock"? > > For all other signals, the tools basically only need to guarantee the routing is > faster than the clock period (+/- small allowance for jitter, clock skew etc); > which at 4Hz or even 40MHz is easy. > > For a clock, the tools must perform a much more rigorous analysis; it is equally > bad for a clock signal to arrive too early as too late! > > I presume your 4Hz clock is driving a simple state machine to blink blink blink; > pause; repeat. > > If the clock delay to each FF in that SM isn't tightly controlled, it will reach > some FFs before their inputs change, and others after their inputs (output from > FFs clocked earlier) change. Hence there is no predicting what the SM will do. > And each routing pass will behave differently; by chance, some may even work! > > >I don't get why tying a std_logic value to a second output pin can be > >a catalyst to a catastrophic failure of an FPGA. > > That can cause the routing to change significantly. > > Don't let it scare you - once you find the groove; avoiding dodgy design areas - > the tools will deliver reliable results. It's not any worse than C's pointer > arithmetic! > > Re: persistence of obsolete pins: how are you generating constraints (UCF > files)? > > If you are using the ISE tools, it's worth checking the UCF file in a text > editor; I just use the editor and forget the tools (which maddeningly force > another synthesis pass first because I updated a comment somewhere) > > I also check the translate (.bld) report, the map (.mrp) report and the PAR > (.par) report; if any of these stages fail, you CAN end up using obsolete files > (at least from the command line) > > - BrianYeah, I only use the UCF file in the text editor. I'll take a look at all those files very carefully. I tried doing a diff at one point between a working version using pin 15 and an non working version using pin13 but nothing jumped up at me. On several occasions I just went into the ucf file with notepad, added a trailing space and saved just to make sure it was touched, Didn't help though.
Reply by ●April 20, 20092009-04-20
On Apr 19, 10:10 am, jleslie48 <j...@jonathanleslie.com> wrote:> On Apr 19, 9:06 am, Brian Drummond <brian_drumm...@btconnect.com> > wrote: > > > > > On Sat, 18 Apr 2009 16:03:33 -0700 (PDT), jleslie48 <j...@jonathanleslie.com> > > wrote: > > > >> One approach would be to generate an enable ( a pulse 1 clk40MHz cycle wide) > > >> from it (easy: e.g. delay it 1 cycle and XOR them for an 8Hz enable) and clock > > >> the actual logic off 40MHz. This will ensure the tool's timing analysis works > > >> correctly and eliminates a major potential set of problems; it may waste a few > > >> mw if that matters. > > > >> Another approach would be to instantiate a BUFG on the 4Hz clock. Then the BUFG > > >> output should be automatically routed on low skew networks and analyzed for > > >> timing hazards. > > >Thanks for the tips. they will be tried/looked at on monday morning. > > >I am confused though. what's the big deal about it being a "clock"? > > > For all other signals, the tools basically only need to guarantee the routing is > > faster than the clock period (+/- small allowance for jitter, clock skew etc); > > which at 4Hz or even 40MHz is easy. > > > For a clock, the tools must perform a much more rigorous analysis; it is equally > > bad for a clock signal to arrive too early as too late! > > > I presume your 4Hz clock is driving a simple state machine to blink blink blink; > > pause; repeat. > > > If the clock delay to each FF in that SM isn't tightly controlled, it will reach > > some FFs before their inputs change, and others after their inputs (output from > > FFs clocked earlier) change. Hence there is no predicting what the SM will do. > > And each routing pass will behave differently; by chance, some may even work! > > > >I don't get why tying a std_logic value to a second output pin can be > > >a catalyst to a catastrophic failure of an FPGA. > > > That can cause the routing to change significantly. > > > Don't let it scare you - once you find the groove; avoiding dodgy design areas - > > the tools will deliver reliable results. It's not any worse than C's pointer > > arithmetic! > > > Re: persistence of obsolete pins: how are you generating constraints (UCF > > files)? > > > If you are using the ISE tools, it's worth checking the UCF file in a text > > editor; I just use the editor and forget the tools (which maddeningly force > > another synthesis pass first because I updated a comment somewhere) > > > I also check the translate (.bld) report, the map (.mrp) report and the PAR > > (.par) report; if any of these stages fail, you CAN end up using obsolete files > > (at least from the command line) > > > - Brian > > Yeah, I only use the UCF file in the text editor. I'll take a look at > all those files very > carefully. I tried doing a diff at one point between a working > version using pin 15 and an non > working version using pin13 but nothing jumped up at me. On several > occasions I just went into > the ucf file with notepad, added a trailing space and saved just to > make sure it was touched, Didn't help though.Ok, I'm looking at the PACE and pinout report, nothing jumps out at me, maybe you can see something. Here's the program that drives the LED, and pins 17, 18. This one works fine: http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap24_led3_working_pins_1718.png and heres the one where all I did was add PIN15_LED, but it locks up the FPGA: http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap25_led3_notworking_pins_1718_15.png I hi-lighted/ red-boxed what appears to me to be the significant lines. It just doesn't make any sense. the UCF file differs by one line, I added: NET "PIN15_led" LOC = "A13"; #"FPGA_IO14" and the top.vhd differs by two, I've added the pin15_led line here: ----------------------------------------------------------------------- ENTITY lprj_TOP IS Port ( -- CLOCKS.UCF SIGNALS SYSTEM_CLOCK : IN STD_LOGIC; -- RS232.UCF SIGNALS RS232_DSR_OUT : OUT STD_LOGIC; HUART_TX_LINE : OUT STD_LOGIC; RS232_CTS_OUT : OUT STD_LOGIC; HUART_RX_LINE : IN STD_LOGIC; --RS232_RTS_IN : IN STD_LOGIC; -- SIGNALS a2mhz_HUART_TX_LINE : OUT STD_logic; a2mhz_HUART_CK_LINE : OUT STD_LOGIC; -- LEDS.UCF SIGNALS led_2 : OUT STD_LOGIC; led_3 : OUT STD_LOGIC; led_4 : OUT STD_LOGIC; led_5 : OUT STD_LOGIC; pin15_led : OUT STD_LOGIC; -- FPGA pin JTAG signals -- dummy placeholders. -- TCK : IN STD_LOGIC; -- TDI : IN STD_LOGIC; -- TDO : in STD_LOGIC; -- TMS : IN STD_LOGIC; -- jtag_or_dummy : OUT STD_LOGIC; -- PUSHBUTTON.UCF SIGNALS button_1 : IN STD_LOGIC; --PB_UP : IN STD_LOGIC; PB_DOWN : IN STD_LOGIC; button_2 : IN STD_LOGIC; PB_RIGHT : IN STD_LOGIC ); ----------------------------------------------------------------------- and in the main body of the behavioral I added this pin15_led line: ----------------------------------------------------------------------- led_3 <= clk_4hz; pin15_led <= not clk_4hz; -- default state for pin 15 is on. ----------------------------------------------------------------------- Sincerely, Jonathan Leslie
