Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
RCIngham wrote: >>Hi >> >>I would like to connect 3 FPGA devices together using a 32-bit bus. Also > > I > >>would like all 3 to be masters on the bus. Is there any standard bus out >>there that would do this rather than me coming up with my own idea. >> >>Jon >> > > PCI would fit the bill, especially if you leverage open-source RTL. > > Is whishbone bus a multi-master bus ? Laurent http://www.amontec.comArticle: 125126
On Oct 16, 5:21 am, avrba...@hotmail.com wrote: > On 16 Okt., 10:17, Laurent Pinchart <laurent.pinch...@skynet.be> > wrote: > > > > > Antti wrote: > > > On 16 Okt., 09:51, Laurent Pinchart <laurent.pinch...@skynet.be> > > > wrote: > > >> Antti wrote: > > >> > Xilinx Spartan3A on custom PCB. > > >> > was working ok > > >> > was stressed VCCINT=1.8V (regulator IC current limit 150ma) > > >> > it does configure ok from external configuration memory > > > >> > JTAG scan returns JTAGID from Virtex-II family. > > > >> > what is wrong? > > > >> Delays in the JTAG chain that shift the data by 1 bit ? Was the JTAGID > > >> manufacturer field still the Xilinx ID ? > > > >> Laurent Pinchart > > > > JTAG ID returned > > > vendor Xilinx > > > family Virtex-II > > > device 0 (invalid) > > > > this same (wrong!) JTAGID returned all the time > > > TDO driven by more than one component ? If two Xilinx parts drive TDO in > > sync (instead of being properly chained) conflicts will occur for the > > family and device ID by not the vendor ID. > > > Laurent Pinchart- Zitierten Text ausblenden - > > > - Zitierten Text anzeigen - > > single IC chain Single IC chain, but is there more than one entity on the chain, say a V2 before/after it. If so, the spartan could have stuck itself in constant pass-through and the other device was the only one responding on the chain. -- MikeArticle: 125127
On 16 Okt., 17:26, morphiend <morphi...@gmail.com> wrote: > On Oct 16, 5:21 am, avrba...@hotmail.com wrote: > > > > > > > On 16 Okt., 10:17, Laurent Pinchart <laurent.pinch...@skynet.be> > > wrote: > > > > Antti wrote: > > > > On 16 Okt., 09:51, Laurent Pinchart <laurent.pinch...@skynet.be> > > > > wrote: > > > >> Antti wrote: > > > >> > Xilinx Spartan3A on custom PCB. > > > >> > was working ok > > > >> > was stressed VCCINT=1.8V (regulator IC current limit 150ma) > > > >> > it does configure ok from external configuration memory > > > > >> > JTAG scan returns JTAGID from Virtex-II family. > > > > >> > what is wrong? > > > > >> Delays in the JTAG chain that shift the data by 1 bit ? Was the JTAGID > > > >> manufacturer field still the Xilinx ID ? > > > > >> Laurent Pinchart > > > > > JTAG ID returned > > > > vendor Xilinx > > > > family Virtex-II > > > > device 0 (invalid) > > > > > this same (wrong!) JTAGID returned all the time > > > > TDO driven by more than one component ? If two Xilinx parts drive TDO in > > > sync (instead of being properly chained) conflicts will occur for the > > > family and device ID by not the vendor ID. > > > > Laurent Pinchart- Zitierten Text ausblenden - > > > > - Zitierten Text anzeigen - > > > single IC chain > > Single IC chain, but is there more than one entity on the chain, say a > V2 before/after it. If so, the spartan could have stuck itself in > constant pass-through and the other device was the only one responding > on the chain. > > -- Mike- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - single chain, single TAP entity in the chain AnttiArticle: 125128
On 16 Okt., 17:04, cs_post...@hotmail.com wrote: > On Oct 16, 6:02 am, avrba...@hotmail.com wrote: > > > it is some FPGA feature that causes it. the reason it happens (in the > > case described) is bound to one specific FPGA device family, but > > similar case is also thinkable and repeatable on other family and > > vendor FPGA with some minor changes > > Something to do with the IO protection diodes? > > Maybe even powering the device or at least an IO bank through the IO > pins and those diodes, rather than through the supply pins? also not so bad suggestion. but now the FPGA is powered from power pins not via phantom IO protection diodes AnttiArticle: 125129
On Oct 15, 2:09 pm, "jacob...@xilinx.com" <naude.j...@gmail.com> wrote: > The newest version ofMIGwill support 32-bitLinuxRed Hat Enterprise > 4.0. The newest version (2.0) will be in IP Update 2 for ISE 9.2i and > will be released on 10/17/2007. > > What device are you targeting? That's very nice! currently XC3S1600E for me... Regards SandroArticle: 125130
paragon.john@gmail.com wrote: > > I do have a gated clock of the following form: GATED_CLOCK <= ENABLE > and not GATED_CLOCK. This signal is not used to clock any flip flops > in the FPGA, it is immediately connected to an output buffer. As long as it is not used internally, I wouldn't worry about it. > > Here is an example unconstrained path: > > -------------------------------------------------------------------------------- > Delay: 1.435ns (data path) > Source: Clk_n (PAD) > Destination: [Flip-flop in hierarchy] (FF) > Data Path Delay: 1.435ns (Levels of Logic = 4) > Constraint Improvement Wizard > Data Path: Clk_n to [Flip-flop in hierarchy] > Delay type Delay(ns) Logical Resource(s) > ---------------------------- ------------------- > Tiopp 0.276 Clk_n > net (fanout=1) 0.000 U_AD_IF/IBUFG_Clk/SLAVEBUF.DIFFIN > Tdiffin 0.812 U_AD_IF/IBUFG_Clk/IBUFDS > net (fanout=1) 0.452 U_AD_IF/BUF_Clk > Tdcmino -2.529 U_AD_IF/DCM_Clk > net (fanout=1) 0.823 U_AD_IF/DCM_Clk_0 > Tgi0o 0.050 U_AD_IF/BUFG_Clk > net (fanout=20886) 1.551 AD_Clk > ---------------------------- --------------------------- > Total 1.435ns (-1.391ns logic, 2.826ns route) > I guess it reports paths that go through the DCM, perhaps because a local net is used. It doesn't look to me like it matters, and that should not be affecting the design operation. Your problem is almost certainly elsewhere. Is your period constraint on the input signal, clk_n? I recognize that if these paths are uninteresting, you want to eliminate them from the report to see if there are any interesting paths left (I doubt you will find your problem that way, but it might help). I suppose you could eliminate the unconstrained paths with a FROM/TO constraint. You could perhaps do a global TIMESPEC "TSPADS2CLK" = FROM "PADS" TO "FFS" 2 ns; Or perhaps try to make it a bit more restricted, though I would have to experiment a bit to find the correct syntax. Perhaps something like: NET "CLK_n" TNM_NET = "CLK_N"; TIMESPEC "TSPADS2CLK" = FROM "CLK_N" TO "FFS" 2 ns;Article: 125131
On 16 Okt., 16:15, "MM" <mb...@yahoo.com> wrote: > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > news:1192513850.557192.144210@q5g2000prf.googlegroups.com... > > > > > FPGA_pin - RESISTOR - LED - GND > > > but as said the LED connection really had nothing todo with the issue > > OK, what's the resistor's value, what's the LED's forward voltage, which > buffer type is used (current limiting?), what's the VCC? > > Unfortunately, I'll be away from my computer for quite a few hours, so I am > probably out of this game... > > /Mikhail NO NO NO the resistor value, LED or IOB characteristics have no influence at all. I will also be away, so you may still get the "it" before others. and mulitply winners will be accepted too, so if someone knows the magic 6 letter word, or can describe the reason-solution otherwise its ok to send private email. all those emails with correct answers that arrive in my mailbox before the public "revealing" of the issue will be accepted as winners (and get the FPGA miniconsole as price) AnttiArticle: 125132
Hi Does anyone have any experiences with connecting a MAC rather than a PHY to a spartan(3e). I don't know yet whether to use a microblaze or my own state machine to connect to the ethernet. For microblaze, xilinx cores seem to want just an external PHY but surely a MAC would offload more stuff from the FPGA. Any thoughts appreciated. Regards ColinArticle: 125133
On Oct 15, 11:39 pm, Eric <sendt...@removethis.yahoo.andthis.com> wrote: > > (serious snippage above) > > > You are trying to build with a mixture of 7.0 and 7.2 components. > > > That will NOT work, web-pack or subscription. At least it never has > > for me... > > > G. > > I thought that might be the problem after I posted so I upgraded to > v7.2. I still got errors so I tried a clean install on a different PC. > The errors are different this time, but I had thought maybe it was still > the license issue so I didn't update. I also tried different builds with > different components. All I really need is the SDRAM controller but it > says I need the avalon master if that's all I select. So I guess I need > the NIOS processor, on-board memory, and SDRAM. With those selected, I > get the errors below. > > Thanks for your help, > Eric > > ----------------- > Info: Info: Elapsed time: 00:00:00 > Info: Starting PTF file elaboration. > 3 [main] sh 4480 fork: child 4880 - died waiting for longjmp > before initialization, errno 11 > c:/altera/72/quartus/sopc_builder/bin/nios_sh: fork: Resource > temporarily unavailable > . > . > . > c:/altera/72/quartus/sopc_builder/bin/nios_sh: fork: Resource > temporarily unavailable > Error: System generation failed. You can't build a NIOS system without a NIOS processor; it just won't let you. (The NIOS processor is the default Avalon master.) The fork call failing could be from just about anything. Two things that come to mind are (1) Running on an unsupported OS, or (2) The web- pack is missing the routine that SOPC is trying to fork to. I would question the use of an Avalon target outside of a NIOS system. If you don't need to support the Avalon fabric, there are better ways of doing it. G. one of two things. There could be more, butArticle: 125134
On Oct 16, 11:30 am, Antti <Antti.Luk...@googlemail.com> wrote: > On 16 Okt., 17:26, morphiend <morphi...@gmail.com> wrote: > > > > > On Oct 16, 5:21 am, avrba...@hotmail.com wrote: > > > > On 16 Okt., 10:17, Laurent Pinchart <laurent.pinch...@skynet.be> > > > wrote: > > > > > Antti wrote: > > > > > On 16 Okt., 09:51, Laurent Pinchart <laurent.pinch...@skynet.be> > > > > > wrote: > > > > >> Antti wrote: > > > > >> > Xilinx Spartan3A on custom PCB. > > > > >> > was working ok > > > > >> > was stressed VCCINT=1.8V (regulator IC current limit 150ma) > > > > >> > it does configure ok from external configuration memory > > > > > >> > JTAG scan returns JTAGID from Virtex-II family. > > > > > >> > what is wrong? > > > > > >> Delays in the JTAG chain that shift the data by 1 bit ? Was the JTAGID > > > > >> manufacturer field still the Xilinx ID ? > > > > > >> Laurent Pinchart > > > > > > JTAG ID returned > > > > > vendor Xilinx > > > > > family Virtex-II > > > > > device 0 (invalid) > > > > > > this same (wrong!) JTAGID returned all the time > > > > > TDO driven by more than one component ? If two Xilinx parts drive TDO in > > > > sync (instead of being properly chained) conflicts will occur for the > > > > family and device ID by not the vendor ID. > > > > > Laurent Pinchart- Zitierten Text ausblenden - > > > > > - Zitierten Text anzeigen - > > > > single IC chain > > > Single IC chain, but is there more than one entity on the chain, say a > > V2 before/after it. If so, the spartan could have stuck itself in > > constant pass-through and the other device was the only one responding > > on the chain. > > > -- Mike- Zitierten Text ausblenden - > > > - Zitierten Text anzeigen - > > single chain, single TAP entity in the chain > > Antti Is it possible that voltage feed for the ID code is sourced from two different locations inside the FPGA and that the first part of the ID is generated properly but the latter becomes erased/garbled?Article: 125135
> You can't build a NIOS system without a NIOS processor; it just won't > let you. (The NIOS processor is the default Avalon master.) > > The fork call failing could be from just about anything. Two things > that come to mind are (1) Running on an unsupported OS, or (2) The web- > pack is missing the routine that SOPC is trying to fork to. > > I would question the use of an Avalon target outside of a NIOS > system. If you don't need to support the Avalon fabric, there are > better ways of doing it. > > G. > > one of two things. There could be more, but > You know, both of my systems are running Vista. I'll try to run it off a WinXP system and see how that goes. That may solve it! What is a better way? I downloaded a SDRAM controller from the Altera site and have been trying to get that to work the last couple of days. I might be close, but looking at what the NIOS system has to offer, it might be a better solution. To give you a better idea of what I'm doing, I'm trying to run an experiment on the radiation effects on DRAM for my thesis. I didn't pick DRAM, my adviser did, and I think he severely underestimated the challenge it would be for a non-computer engineer. I'm an EE but more on the materials side of things (hence the radiation effects). The device needs to be in operation for the test and I just need to write a simple pattern. I do need to control the refresh rate and read from it though. Thanks, EricArticle: 125136
colin wrote:
> Does anyone have any experiences with connecting a MAC rather than a
> PHY to a spartan(3e).
You probably need both.
The PHY is the magic interface to the wire.
The MAC is a digital interface that makes
it all look like registers to some cpu.
It might be on the PHY chip or it might
be a fpga module.
-- Mike Treseler
Article: 125137On Oct 16, 2:33 am, "blisca" <bliscachiocciolinatiscali.it> wrote: > Is it possible to download and install only the newest Impact version? > Thanks once more I think so... I think I remember something about a lab install or technician install or something, that could only program files but not compile themArticle: 125138
Eric wrote:
> To give you a better idea of what I'm doing, I'm trying to run an
> experiment on the radiation effects on DRAM for my thesis. I didn't pick
> DRAM, my adviser did, and I think he severely underestimated the
> challenge it would be for a non-computer engineer. I'm an EE but more on
> the materials side of things (hence the radiation effects). The device
> needs to be in operation for the test and I just need to write a simple
> pattern. I do need to control the refresh rate and read from it though.
Why not start with an fpga demo board
already configured with dram,
an fpga controller module, and a cpu.
All you would need is an HDL wrapper
to cook the refresh.
-- Mike Treseler
Article: 125139On Oct 16, 11:52 am, Duane Clark <junkm...@junkmail.com> wrote: > paragon.j...@gmail.com wrote: > > > I do have a gated clock of the following form: GATED_CLOCK <= ENABLE > > and not GATED_CLOCK. This signal is not used to clock any flip flops > > in the FPGA, it is immediately connected to an output buffer. > > As long as it is not used internally, I wouldn't worry about it. > > > > > > > Here is an example unconstrained path: > > > -------------------------------------------------------------------------------- > > Delay: 1.435ns (data path) > > Source: Clk_n (PAD) > > Destination: [Flip-flop in hierarchy] (FF) > > Data Path Delay: 1.435ns (Levels of Logic = 4) > > Constraint Improvement Wizard > > Data Path: Clk_n to [Flip-flop in hierarchy] > > Delay type Delay(ns) Logical Resource(s) > > ---------------------------- ------------------- > > Tiopp 0.276 Clk_n > > net (fanout=1) 0.000 U_AD_IF/IBUFG_Clk/SLAVEBUF.DIFFIN > > Tdiffin 0.812 U_AD_IF/IBUFG_Clk/IBUFDS > > net (fanout=1) 0.452 U_AD_IF/BUF_Clk > > Tdcmino -2.529 U_AD_IF/DCM_Clk > > net (fanout=1) 0.823 U_AD_IF/DCM_Clk_0 > > Tgi0o 0.050 U_AD_IF/BUFG_Clk > > net (fanout=20886) 1.551 AD_Clk > > ---------------------------- --------------------------- > > Total 1.435ns (-1.391ns logic, 2.826ns route) > > I guess it reports paths that go through the DCM, perhaps because a > local net is used. It doesn't look to me like it matters, and that > should not be affecting the design operation. Your problem is almost > certainly elsewhere. Is your period constraint on the input signal, clk_n? > > I recognize that if these paths are uninteresting, you want to eliminate > them from the report to see if there are any interesting paths left (I > doubt you will find your problem that way, but it might help). I suppose > you could eliminate the unconstrained paths with a FROM/TO constraint. > You could perhaps do a global > TIMESPEC "TSPADS2CLK" = FROM "PADS" TO "FFS" 2 ns; > Or perhaps try to make it a bit more restricted, though I would have to > experiment a bit to find the correct syntax. Perhaps something like: > NET "CLK_n" TNM_NET = "CLK_N"; > TIMESPEC "TSPADS2CLK" = FROM "CLK_N" TO "FFS" 2 ns; The period constraint is on clk_n's differential counterpart clk_p. Similar unconstrained paths appear for clk_p, I just happened to pick one that used clk_n. I will try a FROM/TO constraint to remove them. Since you doubt that going down this path will help me out, do you have any insight on what may be a better way to diagnose possible timing issues that may result in a mismatch? I have looked through the warnings that the various stages of ISE spit and haven't seen any that would lend themselves to a simulation mismatch. Thanks.Article: 125140
Are you using some sort of DDR output flop?Article: 125141
On 16 Okt., 19:25, Jeff Cunningham <j...@sover.net> wrote: > Are you using some sort of DDR output flop? noArticle: 125142
<cs_posting@hotmail.com> wrote in message 1192554870.585680.195010@k35g2000prh.googlegroups.com... > On Oct 16, 2:33 am, "blisca" <bliscachiocciolinatiscali.it> wrote: > > > Is it possible to download and install only the newest Impact version? > > Thanks once more > > I think so... I think I remember something about a lab install or > technician install or something, that could only program files but not > compile them > thanks for this trace,i'll try to follow itArticle: 125143
"Amontec, Larry" <laurent.gauch@ANTI-SPAMamontec.com> writes: > Is whishbone bus a multi-master bus ? Not in the conventional sense. It's not well-suited for an off-chip interconnect.Article: 125144
paragon.john@gmail.com wrote:
> I will try a FROM/TO constraint to remove them. Since you doubt that
> going down this path will help me out, do you have any insight on what
> may be a better way to diagnose possible timing issues that may result
> in a mismatch?
The answer is usually a missing
handshake, synchronizer, transition detector,
clock enable or fifo. These problems are hard
to see at ground level.
It is easier for me to guarantee
synchronization from the top down
than it is to decode cryptic
timing warnings after the fact. This is
the only way I know of to make good
use of simulation.
-- Mike Treseler
Article: 125145avrbasic@hotmail.com wrote: > On 16 Okt., 11:51, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > >>>>Hi Jim, >> >>>>yes the signals are FULLY independant. >> >>>That's as seen on a scope, at the pins ? >>>That moves the issue to downstream of the FPGA . >> >>Any answer on the Scope probe at the LED1,LED2 pins ? >> >>-jg > > > sorry, scope would show the LED1, LED2 signals switching in sync with > with some relatively small skew, perfect no glitch ouput signals Some pin-level (miss) operation could cause this. - such as OE not handled correctly Behaviour does not match pin-keep errors, and a LED off on pos drive, means a LOW going dominant coupling If the Logic IS internally correct, and the LEDs are 'dont care', and VccIOs are OK, then all that is left is an IO Cell / Pin Level strangeness. I take it if you drive 20 leds, they would all exhibit this operation ? - and that you did apply a fix, that cured it - and such Fix must be applied in SW, as you said the PCB/HW/FPGA are all OK ? -jgArticle: 125146
On 16 Okt., 20:44, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > avrba...@hotmail.com wrote: > > On 16 Okt., 11:51, Jim Granville <no.s...@designtools.maps.co.nz> > > wrote: > > >>>>Hi Jim, > > >>>>yes the signals are FULLY independant. > > >>>That's as seen on a scope, at the pins ? > >>>That moves the issue to downstream of the FPGA . > > >>Any answer on the Scope probe at the LED1,LED2 pins ? > > >>-jg > > > sorry, scope would show the LED1, LED2 signals switching in sync with > > with some relatively small skew, perfect no glitch ouput signals > > Some pin-level (miss) operation could cause this. > - such as OE not handled correctly > Behaviour does not match pin-keep errors, and a LED off on pos drive, > means a LOW going dominant coupling > > If the Logic IS internally correct, and the LEDs are 'dont care', > and VccIOs are OK, then all that is left is an IO Cell / Pin Level > strangeness. > > I take it if you drive 20 leds, they would all exhibit this operation ? > - and that you did apply a fix, that cured it - and such Fix must be > applied in SW, as you said the PCB/HW/FPGA are all OK ? > > -jg- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - Jim, logic is correct, Vccio ok, no pin cell level strangeness either. if I connect the signals that driver led1 and led2 to more LEDs then each of them would have similar behaviour as LED1/LED2 depenging what signal is driving them. AnttiArticle: 125147
On Oct 12, 11:10 am, "dadabu...@gmail.com" <dadabu...@gmail.com> wrote: > On 10 10 , 4 50 , "Ju, Jian" <ee...@polyu.edu.hk> wrote: > > > > > > > Hi all, > > > I meet some problems in the P&R process of my design. > > > The Place & Route Report shows the following messages. Because it stoped at > > Phase 6 for a long time, I paused it and it shows there's 1 net unrouted. > > > ----------------- Place & Route Report ------------------------ > > Phase 6: 2645 unrouted; (0) REAL time: 17 secs > > > Ctrl-C interrupt detected. > > > Please choose one of the following options: > > 1. Ignore interrupt and continue processing. > > 2. Exit program normally at next checkpoint. > > This will save the best results so far > > after concluding the current processing. > > 3. Exit program immediately. > > 4. Cancel the current job and move to the next one > > at the next check point. > > > Enter choice --> 2 > > User requested termination > > Phase 7: 1 unrouted; (0) REAL time: 3 mins 2 secs > > ------------------------------------------------------------------------- > > > I opened the ncd file and shows the Unrouted Nets visually. I changed the > > position of one of the SLICE and then it automatically re-route. The > > previously Unrouted Nets dissapered and are no longer listed. > > > But I'm not completely sure that all of the nets have been routed properly, > > because in the following step, Generated Programming File, it complains that > > ERROR:PhysDesignRules:801 - The network <digital_inst/inst1/fir1/N42592> has > > <1> routing conflicts. > > ERROR:PhysDesignRules:801 - The network <digital_inst/inst1/fir1/N42591> has > > <1> routing conflicts. > > ERROR:Bitgen:25 - DRC detected 2 errors and 24 warnings. > > > I checked the ncd file again in the FPGA Editor, however, it seems these two > > nets have already been routed. what is "the routing conflicts" meant to? Any > > possible solutions? > > > I would appreciated your help, > > Ju, Jian > > maybe what you need to do is run generate program file again- Hide quoted text - > > - Show quoted text - Another try, let open a working design in FPGA editor, unroute something and save it off, then try to generate the program file. If you are able to do so, that means you're still generate bit file from the old net...just a though, I do see couple of "failed routing" like that..., just simply re-run all and it works again. If the problem consistent, call Xilinx and "pray" good luckArticle: 125148
Antti wrote: (snip) >>>>vhdl code >>>>LED1 <= some_signal; >>>>LED2 <= blink_one_second; (snip) > the VHDL code for signal LED2 is essentially a single wire point-to- > point it would be single horizontal stright wire in scheamatic > version. Is this VHDL specific? Would verilog do the same thing? (I know verilog much better than VHDL.) -- glenArticle: 125149
Antti wrote: > On 16 Okt., 20:44, Jim Granville <no.s...@designtools.maps.co.nz> >>I take it if you drive 20 leds, they would all exhibit this operation ? >>- and that you did apply a fix, that cured it - and such Fix must be >>applied in SW, as you said the PCB/HW/FPGA are all OK ? >> >>-jg- Zitierten Text ausblenden - >> >>- Zitierten Text anzeigen - > > > Jim, > > logic is correct, Vccio ok, no pin cell level strangeness either. > if I connect the signals that driver led1 and led2 to more LEDs then > each of them would have similar behaviour as LED1/LED2 depenging what > signal is driving them. You did not reply to where SW Fix was, but I see more information is given in c.a.e ?! Seems like this is not a FPGA 'fault' at all, if code in a not-before-mentioned AVR can cure it ? <paste> Antii : > I did originally posted to C.A.F. so sorry for copy to .embedded I > only do repost here as realized later that well, the FPGA is made to > look like working wrong by an Atmel AVR MCU. And the "problem" is > small piece of code that executes on ATmega8. In the matter of fact > its only 1 wrong bit in the Atmel code, by changing one bit in the > Atmel code the FPGA code would work as it is supposed to work. So are we to presume this AVR is providing the stimulus signals, that route thru the working FPGA, and that some Port/RMW issue in the AVR is the culprit ? -jg
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z