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
> > when you generate the EDK project there is a radio button to choose the > PPC debug port to be connected to FPGA logic. just select that option > and connect the PPC jtag pins to ios. It is is also explained in the > Xilinx documentation. > > Antti > http://antti-brain.com Antti you are right: Chipscope and XMD or IMAPACT cannot work in the same JTAG port. Adding another PPC jtag core can work if the sotware is able to destinguish between the two cables - manual cable selection is a must. GuruArticle: 104726
hi,
Does the simulation model provied by the MIG tool work with
synthesized simulation model. When i simulated the code generated by
the mig tool with the simulation model of ddr it's working.But when i
generated the simulation model of the controller after synthesize and
tested it with the ddr model the Error flag pulsing continously after
the initializing sequence.
regards
subin
Article: 104727
mh wrote:
>hi
>how can i instantiate EDN core (exported from PlanAhead) in top level
>of a verilog design , while the core doesnot have any associated I/O
>buffers and gives same error in ISE mapping.
>
>
>
you can create a verilog wrapper, keeping the same ports, and
instantiate the wrapper in your top level verilog. This wrapper will be
empty and XST will cosider it a black box, but ngdbuild should pick up
your edif.
make sure you place the edif in the design directory.
Aurash
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 104728Guru wrote: > Antti you are right: Chipscope and XMD or IMAPACT cannot work in the > same JTAG port. Adding another PPC jtag core can work if the sotware is > able to destinguish between the two cables - manual cable selection is > a must. I use ChipScope and XMD simultaneously from the same JTAG port all the time. --- Joe Samson Pixel VelocityArticle: 104729
When I use FPGAs of Xilinx, the BlockRAM is 1K * 18bit, but the data width I can actually use is only 16bit. The other 2 bits is for read/write check. Then can I use all 18bits of a BlockRAM as the data width(no read/write check)? Thank you, all.Article: 104730
"Evan Lavelle" <eml@nospam.co.uk> wrote in message news:l20na2hjs05c14rrvmt5dcdrh2opl50i74@4ax.com... > On Tue, 04 Jul 2006 18:14:21 -0500, hmurray@suespammers.org (Hal > Murray) wrote: > >> >>>I think the pen analogy is valid... >> >>I use a ball rolling over a speed-bump. It's naturally only >>one dimensional. > > I'm not convinced by these dynamics analogies. These are just unstable > systems in an enery maxima, where a slight perturbation leads to a > more stable, lower energy, configuration. > > In normal (my normal, anyway) usage of the term 'metastable', what's > meant is an asychronous circuit with feedback, in which more than one > input changes 'simultaneously', leading to oscillation because of a > hazard. In practical circuits, the oscillation is damped and decays. > Hi Evan, Not all metastablility manifests itself as an oscillation. e.g. CMOS FFs. In fact a metastable FF doesn't necessarily have to have oscillation or even a 'funny' output voltage. (Imagine a circuit which has a funny output voltage followed by a comparator with large hysteresis) All it must have is an indeterminate clock to output delay. I think you're wise to be unconvinced by dynamics analogies. I agree you need different analogies for different FF technologies, but the pen/speed bump ones are good for what's inside CMOS FFs. Probably! :-) Cheers, Syms. p.s. Just in case you haven't seen it, there some stuff on Philip's website which may be of interest. http://www.fpga-faq.com/FAQ_Pages/0017_Tell_me_about_metastables.htmArticle: 104731
"StanleyLee" <lizhongqi@hotmail.com> wrote in message news:1152099407.309997.161540@a14g2000cwb.googlegroups.com... > When I use FPGAs of Xilinx, the BlockRAM is 1K * 18bit, but the data > width I can actually use is only 16bit. The other 2 bits is for > read/write check. Then can I use all 18bits of a BlockRAM as the data > width(no read/write check)? > > Thank you, all. > Hi Stanley, As you say there are two extra bits, nominally refered to as 'parity check bits' or somesuch, but you have to implement any parity check yourself. So, you can use these bits in the BRAM as regular data bits, no problem, as long as you're in 1k * 18 or even 2k * 9 modes. Cheers, Syms.Article: 104732
"Joseph Samson" <user@example.net> wrote in message news:jbNqg.116175$H71.75047@newssvr13.news.prodigy.com... > Guru wrote: > > Antti you are right: Chipscope and XMD or IMAPACT cannot work in the > > same JTAG port. Adding another PPC jtag core can work if the sotware is > > able to destinguish between the two cables - manual cable selection is > > a must. > I use ChipScope and XMD simultaneously from the same JTAG port all the time. > > > --- > Joe Samson > Pixel Velocity What version of ISE are you running?Article: 104733
Joseph Samson schrieb: > Guru wrote: > > Antti you are right: Chipscope and XMD or IMAPACT cannot work in the > > same JTAG port. Adding another PPC jtag core can work if the sotware is > > able to destinguish between the two cables - manual cable selection is > > a must. > I use ChipScope and XMD simultaneously from the same JTAG port all the time. > > > --- > Joe Samson > Pixel Velocity Hi Joe, sod YOU can arm Chipscope trigger (lets say OPB_IBA on address match), and then start XMD JTAG download or lets say write to some address and you see chipscope triggering on that address !? - this like work setup isnt possible with single JTAG port ASFAIK, or am I wrong here? Sure the PPC and chipscope can co-exist without little problem, but their way of JTAG sharing is not complete IMHO - because XMD and chipscope are developed with different Xilinx branches having intercommunication problem - the lower level JTAG drivers for XMD and chipscope are different so 2 clients can not successfully communicate over the same JTAG AnttiArticle: 104734
JL wrote: > Hello, > > I am using Xilinx ISE 7.1 and VHDL for a project deployed in a Virtex2 > FPGA. I place&route and then I run the static timing analyzer. Results > throw a timing constrain not met (see below). The weird thing is that > it happens after I removed some logic from the project, without adding > anything new. My understanding is that adding new logic could make > place&route harder, but removing logic would give us more room to find > a better allocation of resources. Any hints? Depending on how much you constrain the internals of a design, you may see improvement when the design becomes smaller. However in a relatively unconstrained placement, the placer starts with a seed and pseudorandomly starts to place the components. Because of the nature of this placement, any change can affect the timing in any direction. My suggestion if you have a design that once met the timing and then does not after removing logic, is to try a different setting for the "Starting Placer Cost Table" under the properties for place&route. You may need to select Advanced properties display to see this. This number is the seed for starting the pseudorandom placement. Changing it can often help your results. If after one or two tries you still don't meet timing, you can use multipass place&route, which automates the process of "Cost Table" selection. Good Luck, GaborArticle: 104735
Symon =E5=86=99=E9=81=93=EF=BC=9A > "StanleyLee" <lizhongqi@hotmail.com> wrote in message > news:1152099407.309997.161540@a14g2000cwb.googlegroups.com... > > When I use FPGAs of Xilinx, the BlockRAM is 1K * 18bit, but the data > > width I can actually use is only 16bit. The other 2 bits is for > > read/write check. Then can I use all 18bits of a BlockRAM as the data > > width(no read/write check)? > > > > Thank you, all. > > > Hi Stanley, > As you say there are two extra bits, nominally refered to as 'parity check > bits' or somesuch, but you have to implement any parity check yourself. S= o, > you can use these bits in the BRAM as regular data bits, no problem, as l= ong > as you're in 1k * 18 or even 2k * 9 modes. > Cheers, Syms. Thank you, Symon. Then when I use the blockRAM as 1k * 16 mode, the parity is checked automatically, is it right? And will it spend FPGA resource to do that? Thank you once again.Article: 104736
Antti wrote: > Joseph Samson schrieb: > > >>Guru wrote: >> >>>Antti you are right: Chipscope and XMD or IMAPACT cannot work in the >>>same JTAG port. Adding another PPC jtag core can work if the sotware is >>>able to destinguish between the two cables - manual cable selection is >>>a must. >> >>I use ChipScope and XMD simultaneously from the same JTAG port all the time. >> >> >>--- >>Joe Samson >>Pixel Velocity > > > Hi Joe, > > sod YOU can arm Chipscope trigger (lets say OPB_IBA on address match), > and then start XMD JTAG download or lets say write to some address and > you see chipscope triggering on that address !? - this like work setup > isnt possible with single JTAG port ASFAIK, or am I wrong here? Here is my usual scenario - say I'm debugging my memory controller. I have a ChipScope set up to look at the appropriate signals. I set up the trigger and arm the ChipScope. I go to my XMD window and write to an address (XMD> mwr 0xc0000000 0x00000001, for example). The logic starts up and eventually Chipscope triggers and I look at my signals. I have only used the PLB_IBA once or twice, but I don't think I used the XMD in those cases (debugging a Linux problem). I'm running Windows XP, and I've done this with 7.1i and 8.1i. --- Joe Samson Pixel VelocityArticle: 104737
"Antti" <Antti.Lukats@xilant.com> wrote in message
news:1152103233.635521.258390@m79g2000cwm.googlegroups.com...
> Joseph Samson schrieb:
> sod YOU can arm Chipscope trigger (lets say OPB_IBA on address match),
> and then start XMD JTAG download or lets say write to some address and
> you see chipscope triggering on that address !? - this like work setup
> isnt possible with single JTAG port ASFAIK, or am I wrong here?
You are wrong. (I used to think this too, but I was wrong as well.)
XMD and chipscope are 100% happy to live on the same JTAG chain and cable
connection. I do this all the time (now that I know it works).
However, iMPACT (the programming tool) does not seem to coexist nicely with
either of them...
Cheers,
-Ben-
Article: 104738Joseph Samson schrieb: > Antti wrote: > > Joseph Samson schrieb: > > > > > >>Guru wrote: > >> > >>>Antti you are right: Chipscope and XMD or IMAPACT cannot work in the > >>>same JTAG port. Adding another PPC jtag core can work if the sotware is > >>>able to destinguish between the two cables - manual cable selection is > >>>a must. > >> > >>I use ChipScope and XMD simultaneously from the same JTAG port all the time. > >> > >> > >>--- > >>Joe Samson > >>Pixel Velocity > > > > > > Hi Joe, > > > > sod YOU can arm Chipscope trigger (lets say OPB_IBA on address match), > > and then start XMD JTAG download or lets say write to some address and > > you see chipscope triggering on that address !? - this like work setup > > isnt possible with single JTAG port ASFAIK, or am I wrong here? > > Here is my usual scenario - say I'm debugging my memory controller. I > have a ChipScope set up to look at the appropriate signals. I set up the > trigger and arm the ChipScope. I go to my XMD window and write to an > address (XMD> mwr 0xc0000000 0x00000001, for example). The logic starts > up and eventually Chipscope triggers and I look at my signals. I have > only used the PLB_IBA once or twice, but I don't think I used the XMD in > those cases (debugging a Linux problem). > > I'm running Windows XP, and I've done this with 7.1i and 8.1i. > > > --- > Joe Samson > Pixel Velocity hum interesting, I really assumed that type of triggering does not work with single JTAG port being used. But I dont recall what version was the last one I checked. AnttiArticle: 104739
My application needs a somewhat large memory array, for constant (every clock cycle) sequential read/write access -- the size in question is exactly 64KB (524288 bits). Is a memory block of this size reasonable / possible to do in just VHDL? My FPGA in question is a Spartan-3E, and we have not yet decided upon the exact package yet. If this task is not feasible in VHDL alone, what external RAM device might be recommended? Having the VHDL for access to such an external RAM available for reference would be a big boon here. A side note on how this memory block will be used. One "task" will be iterating over the block repeatedly, with data trickling in replacing old values -- so each incoming byte stored in the RAM will be accessed many times before it is overwritten. Any tips or links to materials regarding this would be greatly appreciated. Thank you. Alex McHaleArticle: 104740
On 5 Jul 2006 06:07:16 -0700, "Stanley Lee" <lizhongqi@hotmail.com> wrote: > >Symon ??? > >> "StanleyLee" <lizhongqi@hotmail.com> wrote in message >> news:1152099407.309997.161540@a14g2000cwb.googlegroups.com... >> > When I use FPGAs of Xilinx, the BlockRAM is 1K * 18bit, but the data >> > width I can actually use is only 16bit. <...> >Then when I use the blockRAM as 1k * 16 mode, the parity is checked >automatically, is it right? And will it spend FPGA resource to do that? > No. When you use 1k *16 mode, all you have is 1K*2 bits unused. To have parity checking, you must wite the parity checker and generator Best regards, ZaraArticle: 104741
Hi all, I would like to debug a system containing a microblze and a ppc405. I'm using the xmd (gdb) for both of these units. I have a single mdm unit and a jtagppc (a single jtag interface). Is there a way to debug both of the processors simultaneously (via two GDBs). Thanks in advance, Mordehay.Article: 104742
Alex wrote: > My application needs a somewhat large memory array, for constant (every > clock cycle) sequential read/write access -- the size in question is > exactly 64KB (524288 bits). > > Is a memory block of this size reasonable / possible to do in just > VHDL? My FPGA in question is a Spartan-3E, and we have not yet decided > upon the exact package yet. > > If this task is not feasible in VHDL alone, what external RAM device > might be recommended? Having the VHDL for access to such an external > RAM available for reference would be a big boon here. > > A side note on how this memory block will be used. One "task" will be > iterating over the block repeatedly, with data trickling in replacing > old values -- so each incoming byte stored in the RAM will be accessed > many times before it is overwritten. > > Any tips or links to materials regarding this would be greatly > appreciated. > > Thank you. > > Alex McHale If you want to do it all internally, the only part big enough is the XC3S1600E. However, you could simply plop on an external SRAM, have enough RAM left over for growth, and get by with a MUCH smaller FPGA. Even better would be an appropriately sized external dual-port RAM. This would allow you to just implement your control logic and data interface in the FPGA, which (depending on your application) could be a much smaller device. FPGA's make for some very expensive RAM. If you need RAM in bulk, it's generally better to just add RAM unless you have some other constraint that forbids it.Article: 104743
>>I use a ball rolling over a speed-bump. It's naturally only >>one dimensional. > >I'm not convinced by these dynamics analogies. These are just unstable >systems in an enery maxima, where a slight perturbation leads to a >more stable, lower energy, configuration. I like the ball because the key idea, energy, is so obvious. It takes energy to change states. You get in trouble when you don't have enough. If the ball is rolling too slowly it won't get over the bump. If the setup/hold times are not met (or the clock pulse isn't clean) you get a runt pulse which doesn't have enough energy to change the state of the FF. >In normal (my normal, anyway) usage of the term 'metastable', what's >meant is an asychronous circuit with feedback, in which more than one >input changes 'simultaneously', leading to oscillation because of a >hazard. In practical circuits, the oscillation is damped and decays. It doesn't take two inputs. You can get metastability with a simple runt pulse into a R/S FF. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 104744
Stanley Lee wrote: > Symon =E5=86=99=E9=81=93=EF=BC=9A > > > "StanleyLee" <lizhongqi@hotmail.com> wrote in message > > news:1152099407.309997.161540@a14g2000cwb.googlegroups.com... > > > When I use FPGAs of Xilinx, the BlockRAM is 1K * 18bit, but the data > > > width I can actually use is only 16bit. The other 2 bits is for > > > read/write check. Then can I use all 18bits of a BlockRAM as the data > > > width(no read/write check)? > > > > > > Thank you, all. > > > > > Hi Stanley, > > As you say there are two extra bits, nominally refered to as 'parity ch= eck > > bits' or somesuch, but you have to implement any parity check yourself.= So, > > you can use these bits in the BRAM as regular data bits, no problem, as= long > > as you're in 1k * 18 or even 2k * 9 modes. > > Cheers, Syms. > > Thank you, Symon. > Then when I use the blockRAM as 1k * 16 mode, the parity is checked > automatically, is it right? And will it spend FPGA resource to do that? > > Thank you once again. The last time I used *9 / *18 / *36 mode block rams, I instantiated them as such and they exposed themselves as those *8 + the parity bit. Look for the instantiation template and you'll see what I mean. Just assign your ninth bit (for each block ram) to the parity bit. Cheers PeteSArticle: 104745
radarman wrote: > If you want to do it all internally, the only part big enough is the > XC3S1600E. However, you could simply plop on an external SRAM, have > enough RAM left over for growth, and get by with a MUCH smaller FPGA. > Even better would be an appropriately sized external dual-port RAM. > This would allow you to just implement your control logic and data > interface in the FPGA, which (depending on your application) could be a > much smaller device. > > FPGA's make for some very expensive RAM. If you need RAM in bulk, it's > generally better to just add RAM unless you have some other constraint > that forbids it. This is along the lines of what I expected. Dual port ram is definitely a possibility, do you have any suggestions as to a part? Like I said, I'd be looking for a minimum of 64KB. On one side of the DP RAM would be the Spartan-3E, and on the other would be a NetBurner module (a pretty average microcontroller). Thank you! Alex McHaleArticle: 104746
Here's a little table I've knocked up after looking at those DSP48s in
the FPGA editor:
DSP48 Name Mmult__n00001 Mmult__n00002 Mmult__n00003 Mmult__n00004
AREG 2 2
2 2
BREG 2 0
2 0
CREG 0 0
0 0
MREG 0 0
0 0
PREG 0 0
0 0
LEGACY_MODE MULT18X18 MULT18X18 MULT18X18 MULT18X18
CARRYINSELREG 0 0 0
0
OPMODEREG 0 0 0
0
SUBTRACTREG 0 0 0
0
CARRYINREG 0 0 0
0
B_INPUT DIRECT CASCADE DIRECT
CASCADE
Cheers,
Robin
Martin Thompson wrote:
> "Robin Bruce" <robin.bruce@gmail.com> writes:
>
> > Martin,
> >
> > > Have you had a look in FPGA editor to see what's going on?
> >
> > This is where I myself look dim: I did open up the NCD file in the FPGA
> > Editor. I didn't really know what to do to tell if the right
> > registering was occurring. All I could see was that all 4 DSP48s were
> > instantiated together in a little row. I've never used FPGA editor
> > before. I'm more familiar with PlanAhead for looking at that sort of
> > thing, but I don't have that on my laptop, my current working platform.
> >
>
> I haven't looked at a V-4 in FPGA editor... but if you go to one of
> your DSP48 blocks and double click it, can you see the intrnals of it
> and are there some boxes that are filled in for the use of registers?
>
> > This is the critical path that comes out of the synthesis report if
> > this means anything to anyone:
> >
> > Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35
> > Gate Net
> > Cell:in->out fanout Delay Delay Logical Name (Net Name)
> > ---------------------------------------- ------------
> > DSP48:CLK->PCOUT47 1 4.399 0.000 mult_inst/Mmult__n00001
> > (mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47)
> > DSP48:PCIN47->PCOUT47 1 2.363 0.000
> > mult_inst/Mmult__n00002
> > (mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47)
> > DSP48:PCIN47->PCOUT47 1 2.363 0.000
> > mult_inst/Mmult__n00003
> > (mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47)
> > DSP48:PCIN47->P35 1 2.270 0.534 mult_inst/Mmult__n00004
> > (mult_inst/Mmult__n0000_s_69)
> > FD:D 0.391 mult_inst/Mmult__n0000_0
> > ----------------------------------------
> > Total 12.320ns (11.786ns logic, 0.534ns route)
> > (95.7% logic, 4.3% route)
> >
>
> That looks like a cascade-chain... because your inputs are 35 bits
> wide and you use more than one multiplier, they need to cascade. This
> can be pipelined (by the look of the DSP48 diagram in UG073), but how
> you'd infer that I have no idea :-( You may have to infer the
> individual multipliers and the regs between them. But at that point,
> you might as well instantiate them!
>
> Cheers,
> Martin
>
> --
> martin.j.thompson@trw.com
> TRW Conekt - Consultancy in Engineering, Knowledge and Technology
> http://www.trw.com/conekt
Article: 104747The XC3S1500 has enough (576 K bits) of dual-ported RAM inside the FPGA. You decide whether that is economical or not. External SRAM need not be dual-ported, can be single-ported, if you have enough nanoseconds to time-multiplex. I believe external dual-ported RAM is exotic and expensive. Internal BlockRAM is dual-ported "for free". Peter Alfke, Xilinx ============ Alex wrote: > My application needs a somewhat large memory array, for constant (every > clock cycle) sequential read/write access -- the size in question is > exactly 64KB (524288 bits). > > Is a memory block of this size reasonable / possible to do in just > VHDL? My FPGA in question is a Spartan-3E, and we have not yet decided > upon the exact package yet. > > If this task is not feasible in VHDL alone, what external RAM device > might be recommended? Having the VHDL for access to such an external > RAM available for reference would be a big boon here. > > A side note on how this memory block will be used. One "task" will be > iterating over the block repeatedly, with data trickling in replacing > old values -- so each incoming byte stored in the RAM will be accessed > many times before it is overwritten. > > Any tips or links to materials regarding this would be greatly > appreciated. > > Thank you. > > Alex McHaleArticle: 104748
Hmmm.... that looks fairly mangled. Try again... Incidentally, these are for an unsigned version of the problem I've been describing, for which the problem is the same. DSP48 Name DSP1 DSP2 DSP3 DSP4 AREG 2 2 2 2 BREG 2 0 2 0 CREG 0 0 0 0 MREG 0 0 0 0 PREG 0 0 0 0 LEGACY_MODE MULT18X18 CARRYINSELREG 0 0 0 0 OPMODEREG 0 0 0 0 SUBTRACTREG 0 0 0 0 CARRYINREG 0 0 0 0 B_INPUT DIRECT CASCADE DIRECT CASCADE Robin > > > Martin Thompson wrote: > > "Robin Bruce" <robin.bruce@gmail.com> writes: > > > > > Martin, > > > > > > > Have you had a look in FPGA editor to see what's going on? > > > > > > This is where I myself look dim: I did open up the NCD file in the FPGA > > > Editor. I didn't really know what to do to tell if the right > > > registering was occurring. All I could see was that all 4 DSP48s were > > > instantiated together in a little row. I've never used FPGA editor > > > before. I'm more familiar with PlanAhead for looking at that sort of > > > thing, but I don't have that on my laptop, my current working platform. > > > > > > > I haven't looked at a V-4 in FPGA editor... but if you go to one of > > your DSP48 blocks and double click it, can you see the intrnals of it > > and are there some boxes that are filled in for the use of registers? > > > > > This is the critical path that comes out of the synthesis report if > > > this means anything to anyone: > > > > > > Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35 > > > Gate Net > > > Cell:in->out fanout Delay Delay Logical Name (Net Name) > > > ---------------------------------------- ------------ > > > DSP48:CLK->PCOUT47 1 4.399 0.000 mult_inst/Mmult__n00001 > > > (mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47) > > > DSP48:PCIN47->PCOUT47 1 2.363 0.000 > > > mult_inst/Mmult__n00002 > > > (mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47) > > > DSP48:PCIN47->PCOUT47 1 2.363 0.000 > > > mult_inst/Mmult__n00003 > > > (mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47) > > > DSP48:PCIN47->P35 1 2.270 0.534 mult_inst/Mmult__n00004 > > > (mult_inst/Mmult__n0000_s_69) > > > FD:D 0.391 mult_inst/Mmult__n0000_0 > > > ---------------------------------------- > > > Total 12.320ns (11.786ns logic, 0.534ns route) > > > (95.7% logic, 4.3% route) > > > > > > > That looks like a cascade-chain... because your inputs are 35 bits > > wide and you use more than one multiplier, they need to cascade. This > > can be pipelined (by the look of the DSP48 diagram in UG073), but how > > you'd infer that I have no idea :-( You may have to infer the > > individual multipliers and the regs between them. But at that point, > > you might as well instantiate them! > > > > Cheers, > > Martin > > > > -- > > martin.j.thompson@trw.com > > TRW Conekt - Consultancy in Engineering, Knowledge and Technology > > http://www.trw.com/conektArticle: 104749
Hi All, I'm trying to develop a serial link using the Aurora protocol between 2 MGT's on a V2pro FF672 based ML321 board. Currently, I'm trying to use the "Using High Speed Serial MGTs with the Aurora IP" sample design offered by the Xilinx University program as a starting point(http://www.xilinx.com/univ/XUPV2P/Quickstarts/xupv2p_aurora.zip) I went through the process described in the quickstart guide and got the Modelsim simulation to work. But, I'm having some issues using Chipscope to monitor the link. I compiled the design in ISE, and configured the FPGA module in Chipscope using the bit file. Once I hit the arm and trigger button; it keeps giving me a message "Waiting for core to be armed, slow or stopped clock" I believe I've instantiated the clock modules in the ucf file correclty (I just used the sample ucf generated by aurora 2.2 & the sample ucf file provided w/ the design) I recently used the board to run the XAPP661, so I do know that onboard clock works properly. Can you think of any other reasons why Chipscope might fail to acquire data from the board. (My labmate thinks its possible that the design is not even uploaded to the FPGA even though its configured in Chipscope because the FPGA chip doesnt get hot/warm) Thanks in advance, Billu
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