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
The problem you reported on the I/O register clear polarity is a real problem in the Designer software (Thank you for pointing it out) and will be fixed in the next service pack of the software.Article: 79301
Hello: Does anyone have a opb vga core for the MicroBlaze? ThanksArticle: 79302
Bo said the following: > I am trying to put the PPC405 asleep on a VirtexIIPro ML310 Xilinx > development board and not have a lot of luck. I'm running VxWorks and have > written a little application that toggles an LED so that I know the task is > running. I've tried two methods--with drastically different results-- but > neither of which do everything I need. > > First try: > > I loaded my app that toggles LEDs via a Tornado shell. > > Spawn the LED toggler. > > Note that via Tornado shell, I see LED toggler in the task list at an "i" > command. Note that via the serial shell, I cannot see LED toggler in the > task list at an "i" command. Well, I'd expect you see it, but not with the expected symbolic name. As you loaded the code via host shell, you'd need to include host sym table sync to your target's image. > > Disable PIT, so only a UART or network source interrupt will awaken me (ie > no sysClk/timer interrupts) > > Put to sleep via MSR[WE]. Observed LED quits toggle-- as expected. > > Then, via a SERIAL shell, I type "i", and vxWorks awoke and printed the > tasks data as expected-but the LED toggler did not resume execution. > How should it? You disabled timer interrupt! > Second try: > > I moved all this code into UsrAppInit and then programmatically, spawned the > LED toggler. Wait a few secs (so I can observe LED on scope). Then Disable > PIT and put to sleep. > > Now, I try to awaken the PPC405 via the serial connection. I cannot seem to > waken the PPC at all. If/when it wakens, the next line of code in usrAppInit > would have printed out an "Awoken" message--but I never see this happen. > > Note that the Msr register is set to 0x00069200 to initiate the sleep-which > should set the sleep bits, and enable critical and external interrupts > (though the PIT as a possible feeder to External Interrupt has been disabled > via a write to TCR of 0x00040000...) > > Someone else had mentioned to me the need for possible sync and orderly > execution before putting the PPC to sleep, so I added "sync, isync, and > eieio" code immediately prior to the set MSR[WE] bit, but this made no > difference. Any ideas? > First action in your UART's ISR should be to re-enable timer interrupt. This is a major device, VxWorks can't run without it properly. HTH -- Regards, Mit freundlichen Grüßen, Michael Lawnick HTML-Mail is the first choice to distribute EMail-worms and -virii. Back to the roots!Article: 79303
Hi! > Does anyone have a opb vga core for the MicroBlaze? I have one. However it is not generic at the moment. You would have to calculate the needed values for the timing-generation yourself (atm it uses a pixel clock of 21.5MHz). However I have problems with the bandwith of the OPB-Bus. It seems that it is too slow to deliver the needed video data. The best solution I think is to merge the VGA controller into the RAM controller. MatthiasArticle: 79304
Hi all,
I have two questions:
1. I implemented a binary constant divider in VHDL with my fixed
point number system.The constant is 0.5. Its signed(1,7). one
bit for the sign and the rest seven bits for the fraction part.
All my values are
between (1,-1). My divider works fine but my question is WHY
does it work fine? It may sound funny but I dont fully
understand the theory behind it. I just saw a pattern in
calculations and wrote my code in VHDL. please help/advise?
ENTITY divider is
PORT( a : IN unsigned(7 DOWNTO 0);
o : OUT unsigned(7 DOWNTO 0));
END divider;
ARCHITECTURE behavior OF divider IS
BEGIN
o(7)<= a(7);
o(6)<= a(5);
o(5)<= a(4);
o(4)<= a(3);
o(3)<= a(2);
o(2)<= a(1);
o(1)<= a(0);
o(0)<= not a(6);
END behavior;
2. Whats the best way to get to know the combinational delay while
using the free Xilinx WebPack tool? When we
synthesize the design, the synthesis report does give a "Maximum
combinational path delay ". Is that what I should
be looking at or is it just an estimate??
Thanks in advance
Sourabh
Article: 79305Hi SD u can do the timing analysis for ur design using Xilinx's Timing Analyzer. This tool gives a detailed description about the critical path covered on ur design.Article: 79306
Clemens Reinrich wrote: > Hello >=20 > I have implemented a FSL core for the Microblaze processor. It is a ver= y > easy test programm, and now I wanna try to use chipscope to take a look= at > the internal registers of my Core. I think this is achivable with Chips= cope, > so is there somewhere a useful tutorial which explains me step by step = what > I have to do to be able to read out data from my core? Would be very > thankful for usefull tips >=20 > Best Wishes > Clemens >=20 >=20 >=20 It shouldn't be any problem at all. Use ChipScope Inserter after=20 synthesis and before implementation of the system. In the inserter you=20 should be able to connect the ChipScope core to the signals of your core.= After the insertion of the core in your system netlist you just continue = the design flow with the ngdbuild, map, par, bitgen, bitinit and impact. I did this over a year ago, and at that time I had to move some files=20 generated by the ngdbuild to the implementation directory manually.=20 Below is an example of the commandos I used at the command line. ngdbuild -sd implementation/ -p xc2v1000fg456-6 -nt timestamp -bm=20 implementation/system.bmm -uc data/system.ucf system.ngo mv ddr_v1_00_b_virtex2_async_fifo.ngo=20 implementation/ddr_v1_00_b_virtex2_async_fifo.ngo mv system_ngdbuild.nav implementation/system_ngdbuild.nav mv netlist.lst implementation/netlist.lst mv system.bld implementation/system.bld mv system.ngd implementation/system.ngd map -o implementation/system_map.ncd implementation/system.ngd=20 implementation/system.pcf par -w -ol 2 implementation/system_map.ncd implementation/system.ncd=20 implementation/system.pcf bitgen -w -f etc/bitgen.ut implementation/system bitinit system.mhs -pe microblaze_0 microblaze_0/code/xmdstub.elf -bt=20 implementation/system.bit -o implementation/download.bit impact -batch etc/download.cmd I don't know if this is of any help for you, but it might point you in=20 the right direction at least... --=20 ----------------------------------------------- Johan Bernsp=E5ng, xjohbex@xfoix.se Research engineer Swedish Defence Research Agency - FOI Division of Command & Control Systems Department of Electronic Warfare Systems www.foi.se Please remove the x's in the email address if replying to me personally. -----------------------------------------------Article: 79307
Surely someone know how? There are bound to be command line options for those implementing core gen functions?Article: 79308
hi all I am starting practicing the multi-thread programming and a simple example is working in desktop linux machine. After trying in same example in EDK with microblaze (standalone), the error message is ---- TestApp/src/TestApp.c : in function 'main': TestApp/src/TestApp.c : 12 'pthread_t' undeclared ... ---- so it seems that EDK tool chain does not have pthread library and header file. How can we fix this problem ? Anyone have experience on this?Article: 79309
hello all, I've made a prototype board with an XC9572XL CPLD (3.3V). I'm currently building a parallel programming cable version II (?)(http://www.xilinx.com/support/programr/files/0380507.pdf) I wonder wether I can set Vcc to 3.3V or not since parallel port I/O are 5V (but logic levels migth be tolerant). If not, is the XC9572XL device programmable with a 5V powered cable? Does anyone have the schematics of a parallel cable version III or IV? Thanks for your help.Article: 79310
Sourabh, it seems that you are actually performing a multiplication by 2 ( x / 0.5 = x * 2) and so the sign remains the same band the other bits are one position left shifted. to me it seems that your module should not give proper result if a(6) = 1 and even the value of o(0) should be always zero but this happens only if a(6) = 0... so now i am a bit confused... does it give any clue? andreaArticle: 79311
On Wed, 16 Feb 2005 07:33:08 -0800, Austin Lesea <austin@xilinx.com> wrote: >Paul, > >I agree. > >Austin Now I've seen everything. - Brian ( p.s. thanks to you both for the discussions!)Article: 79312
hi Final --: questions are about the suggestions above- multi-programming and FSL. I find FSL is a point2point link in the product specification. It seems that two approaches are totally different. Does EDK support such a multi-programming? If yes, in which way? How can we emulate the shared memory hardware and software (for example, threaded programming) in Xilinx tool? 2 microblazes with FSL and shared memory ; this looks very exotic and it seems that we still have two independent main() routines. In any case, it will be interesting that one main() routine transperently describe an algorithm and two microblazes coorperate each other. By the way, thankyou very much, G=F6ranArticle: 79313
On 16 Feb 2005 06:51:44 -0800, "a0-0b" <e-mail@andrew-brown.org> wrote:
>Does anyone have any idea how i can generate the UCF required for an
>RPM without manually running the floorplanner? (so i can create the
>RPM from a makefile) the floorplanner does not apparently have a
>"batch mode" despite a reference to a <script_file> in the help - which
>is apparently not supposed to be there!
>I've got a hierarchical design builtup of many sub-blocks implemented
>as RPMs, so for each design change i need to rebuild the RPMs and
>recreate the full chip.
>A nightmare if i have to run the floorplanner interactively!
I'm not sure I see what you need.
If you know what you want to put in the UCF, you can generate it in a
text editor or from scripts. Similarly, you can convert an absolute
placement("LOC=SLICE_X0Y0") UCF file to relative placement ("RLOC=X0Y0)
in a text editor via global find/replace, and it'll work. Relocating
elements should be possible with PERL scripts or similar.
There are bugs in the flow, which should go away in the 7.1 tool release
... meanwhile, it is good to occupy the lower left corner of the
rectangle surrounding your RPM with one of its components ( i.e. an "L"
or "E" shape is good, "T" or "+" will give unexpected results ), and
place RPMs on even X and Y locations (otherwise the mapper may move them
around).
Having got an RPM ("RLOC") UCF, you can create the RPM .NGC from the
command line with NGCbuild. (An example command line will be found in
the .blc report file created when you built the RPM in the floorplanner)
So it is all possible without the floorplanner ... though the
floorplanner is probably the easiest way to make some kinds of changes.
Or am I misunderstanding what you are trying to do?
- Brian
Article: 79314"Rene Tschaggelar" <none@none.net> wrote in message news:42122fbb$0$3410$5402220f@news.sunrise.ch... > Kenneth Land wrote: > >> Hello, >> >> I'm having a hard time fitting the two fifo's I need into my StratixI >> device (EPS10) because of the power of 2 requirement on the depth. >> >> Are there any fifo variants that lift this requirement? >> >> Right now we're instantiating 2 sc_fifo's within a AHDL file. (I need >> two 3600 word fifos which would fit, but have to use two 4096 word fifos >> which do not fit) >> >> I'm aware of the FIFO Partitioner, but would like to avoid this if >> possible. > > > Would it be thinkable to have multiple FIFOs behind each other ? > EG a 2048 & 1024 & 512 ? > > Rene > -- > Ing.Buero R.Tschaggelar - http://www.ibrtses.com > & commercial newsgroups - http://www.talkto.net Hi Rene, How would this work? A little latency wouldn't hurt. Is it very tricky to stack fifo's? Thanks, KenArticle: 79315
"Gabor" <gabor@alacron.com> wrote in message news:1108496252.756870.206390@l41g2000cwc.googlegroups.com... > > Peter Sommerfeld wrote: >> Hi Ken, >> >> I've done this before by writing my own fifo using the altsyncram >> megafunction. altsyncram has a parameter MAXIMUM_DEPTH which allows >> non-power-of-2 depths. Adding single-clock FIFO functionality (read > and >> write ptr management at a minimum) shouldn't be more than 20 lines of >> HDL. You can go one step further and implement "stacked" memory >> yourself, but then you have to write the muxing yourself, which >> altsyncram does implicitly with MAXIMUM_DEPTH. >> >> -- Pete > > If you need asynchronous operation (2 clocks) you could mix both > methods > using a synchronous (single clock) FIFO after the async one. Of course > cascading FIFO's will increase the latency. > Hi Pete and Gabor, I'm not HDL savvy enough myself, but I could handle the code if its available :) My application can stand a little latency if cascading fifo's is easy. Is this cascading easy or are there examples on the net somewhere? One other thing is that I don't need a free solution. Thanks, KenArticle: 79316
Michael, Thanks for taking a look. I changed the ext int ISR in vxWorks to always set the PIT enable and PIT auto-reload bits (in case the execution of ISR was the first execution after being put to sleep) and got the exact same results. Any ideas? You were right that the LED toggler did show up in the "i" command response--under a different name-and as 'READY'--however it was not executing. (???) Thanks again... Paul "Michael Lawnick" <m.lawnick@kontron-applications.de> wrote in message news:4214442d_2@news.arcor-ip.de... > Bo said the following: >> I am trying to put the PPC405 asleep on a VirtexIIPro ML310 Xilinx >> development board and not have a lot of luck. I'm running VxWorks and >> have >> written a little application that toggles an LED so that I know the task >> is >> running. I've tried two methods--with drastically different results-- but >> neither of which do everything I need. >> >> First try: >> >> I loaded my app that toggles LEDs via a Tornado shell. >> >> Spawn the LED toggler. >> >> Note that via Tornado shell, I see LED toggler in the task list at an "i" >> command. Note that via the serial shell, I cannot see LED toggler in the >> task list at an "i" command. > Well, I'd expect you see it, but not with the expected symbolic name. As > you loaded the code via host shell, you'd need to include host sym table > sync to your target's image. > >> >> Disable PIT, so only a UART or network source interrupt will awaken me >> (ie >> no sysClk/timer interrupts) >> >> Put to sleep via MSR[WE]. Observed LED quits toggle-- as expected. >> >> Then, via a SERIAL shell, I type "i", and vxWorks awoke and printed the >> tasks data as expected-but the LED toggler did not resume execution. >> > How should it? > You disabled timer interrupt! > >> Second try: >> >> I moved all this code into UsrAppInit and then programmatically, spawned >> the >> LED toggler. Wait a few secs (so I can observe LED on scope). Then >> Disable >> PIT and put to sleep. >> >> Now, I try to awaken the PPC405 via the serial connection. I cannot seem >> to >> waken the PPC at all. If/when it wakens, the next line of code in >> usrAppInit >> would have printed out an "Awoken" message--but I never see this happen. >> >> Note that the Msr register is set to 0x00069200 to initiate the >> sleep-which >> should set the sleep bits, and enable critical and external interrupts >> (though the PIT as a possible feeder to External Interrupt has been >> disabled >> via a write to TCR of 0x00040000...) >> >> Someone else had mentioned to me the need for possible sync and orderly >> execution before putting the PPC to sleep, so I added "sync, isync, and >> eieio" code immediately prior to the set MSR[WE] bit, but this made no >> difference. Any ideas? >> > First action in your UART's ISR should be to re-enable timer interrupt. > This is a major device, VxWorks can't run without it properly. > > HTH > > -- > Regards, > Mit freundlichen Grüßen, > Michael Lawnick > > HTML-Mail is the first choice to distribute EMail-worms and -virii. > Back to the roots!Article: 79317
Kenneth Land wrote: > "Gabor" <gabor@alacron.com> wrote in message > news:1108496252.756870.206390@l41g2000cwc.googlegroups.com... > > > > Peter Sommerfeld wrote: > >> Hi Ken, > >> > >> I've done this before by writing my own fifo using the altsyncram > >> megafunction. altsyncram has a parameter MAXIMUM_DEPTH which allows > >> non-power-of-2 depths. Adding single-clock FIFO functionality (read > > and > >> write ptr management at a minimum) shouldn't be more than 20 lines of > >> HDL. You can go one step further and implement "stacked" memory > >> yourself, but then you have to write the muxing yourself, which > >> altsyncram does implicitly with MAXIMUM_DEPTH. > >> > >> -- Pete > > > > If you need asynchronous operation (2 clocks) you could mix both > > methods > > using a synchronous (single clock) FIFO after the async one. Of course > > cascading FIFO's will increase the latency. > > > > Hi Pete and Gabor, > > I'm not HDL savvy enough myself, but I could handle the code if its > available :) > My application can stand a little latency if cascading fifo's is easy. > Is this cascading easy or are there examples on the net somewhere? > Cascading is fairly simple. The only thing you do extra is control data flowing between FIFO's. The first FIFO would be read whenever the second FIFO is not full and not almost full (full - 1). The almost full is required to prevent data read on one clock from writing a full FIFO on the next. Then the second FIFO is written when new data is read from the first. I haven't used Altera FIFO's but usually this is one clock cycle after reading a non-empty first fifo. If you have independent read and write clocks, the first FIFO could be single-clock using the write clock for the second FIFO. Alternately you could make the first FIFO dual-clocked and the second FIFO single- clocked using the read clock from the first FIFO. The second approach may be easier for the almost-full flag implementation, since it is easier to produce flags in a single-clock design. With Xilinx designs I use the COREgen FIFO's and this approach works either way. > One other thing is that I don't need a free solution. > > Thanks, > KenArticle: 79318
Bo said the following: > Michael, > > Thanks for taking a look. I changed the ext int ISR in vxWorks to always set > the PIT enable and PIT auto-reload bits (in case the execution of ISR was > the first execution after being put to sleep) and got the exact same > results. Any ideas? > > You were right that the LED toggler did show up in the "i" command > response--under a different name-and as 'READY'--however it was not > executing. (???) > For both problems: make _sure_ that your PIT is getting reenabled on UART-int. You could do it by attaching an ISR that toggles the LED ;-) As long as PIT doesn't work properly, scheduling of tasks that are on taskDelay() won't work anymore. Other tasks pending on semaphores will work nevertheless. -- Regards, Mit freundlichen Grüßen, Michael Lawnick HTML-Mail is the first choice to distribute EMail-worms and -virii. Back to the roots!Article: 79319
Hi John,
In case you don't have the code all sorted yet, here's a tutorial on how to
change the megawizard generated module to pass down the hex file parameter
you need (thanks to one of our megafunction gurus):
You need to parameterize the wizard generated blackbox module.
By default, the wizard generated module is fully customized according to the
user selection in the wizard.
If you need to instantiate multiple instances which are variations of a base
module, you can parameterize the variation in the base module.
For example, the following would be a typical wizard generated ROM module.
module myrom (
address,
clock,
q);
input [4:0] address;
input clock;
output [7:0] q;
wire [7:0] sub_wire0;
wire [7:0] q = sub_wire0[7:0];
altsyncram altsyncram_component (
.clock0 (clock),
...
...
.q_a(sub_wire0));
defparam
altsyncram_component.operation_mode = "ROM",
....
....
altsyncram_component.init_file = "test.mif",
....
You can parameterize the above module by changing it to the following (I
highlighted the change in red)
module myrom (
address,
clock,
q);
input [4:0] address;
input clock;
output [7:0] q;
parameter mif_file = "test.mif";
wire [7:0] sub_wire0;
wire [7:0] q = sub_wire0[7:0];
altsyncram altsyncram_component (
.clock0 (clock),
...
...
.q_a(sub_wire0));
defparam
altsyncram_component.operation_mode = "ROM",
....
....
altsyncram_component.init_file = mif_file,
....
And now they can instantiate the instance with different mif_file on the
upper level source.
"John Rible" <jrible@sandpipers.com> wrote in message
news:cuuoep0fmo@enews4.newsguy.com...
>
> Subroto Datta wrote:
>> Hi John,
>>
>> You will need to expose the parameter that is used for the .hex
>> initialization file. The MegaWizard-generated Verilog file will have a
>> line saying defparam <instname>.INIT_FILE = "foo.hex"; that parameter
>> needs to be added to the MegaWizard-generated module and passed down.
>> Then assign a unique value for that parameter to each instantiation of
>> the wizard-generated ROM sub-module.
>
> I've already tried using defparam (without adding it to the top file) and
> got:
> Error: Verilog HDL or VHDL error at c18m.v(78): Unconverted VERI-2009: no
> support for cross-hierarchy defparam id
> c.RS.m.altsyncram_component.init_file
>
> Tomorrow I'll 'expose' the parameter. Also, Verilog 1995 didn't support
> string parameters; is that the problem?
>
>> As for the question on inversions: all our blocks have programmable
>> inversions on the inputs, so we allow inverts to be absorbed across
>> hierarchy boundaries. The solution would be to insert an LCELL buffer to
>> prevent the programmable inversion being propagated.
>>
>>
>>
>> Where the code has
>>
>>
>>
>> wire inverted_signal;
>>
>>
>>
>> You will need to add
>>
>> wire buffered_inverted_signal;
>>
>> lcell lcell_inst (inverted_signal, buffered_inverted_signal);
>>
>>
>>
>> and this will prevent the inversion propagating. However, It will use up
>> an LE.
>
> Thanks a lot!
>
> -John
>
>> Hope this helps,
>>
>> Subroto Datta
>>
>> Altera Corp.
Article: 79320Since both processors starts at address 0, they will start to execute the same initialization code. You need to use a FSL port with different constant signals for each MicroBlaze. The boot code would then read the FSL port to know which MicroBlaze it's. Using this it would jump to the right code section. I would have all code tied on one processor and letting the other processor using this as in will start to execute the same program. Our JTAG debug module handles concurrently up to 8 MicroBlazes in parallel so there is no problem debugging this. You will get a gdb window for each MicroBlaze. It can all be done in the current tools, so just start and have some fun. Göran Elinore wrote: > hi > > Final --: questions are about the suggestions above- multi-programming > and FSL. > I find FSL is a point2point link in the product specification. > It seems that two approaches are totally different. > Does EDK support such a multi-programming? If yes, in which way? How > can we emulate the shared memory hardware and software (for example, > threaded programming) in Xilinx tool? > > 2 microblazes with FSL and shared memory ; this looks very exotic and > it seems that we still have two independent main() routines. > In any case, it will be interesting that one main() routine > transperently describe an algorithm and two microblazes coorperate > each other. > > By the way, thankyou very much, Göran >Article: 79321
Thanks for Norm's request for clarification about the form in which Samplify's sampled data compression is available. While Samplify Systems is targeting the high-speed data acquisition and signal processing markets that usually use DSP chips (from TI, Freescale, Analog Devices, etc.) and FPGAs (from Xilinx and Altera), we are happy to discuss other embedded target environments in which C source code might be required. Samplify is a low-MIPS algorithm that runs at 10+ Msamp/sec compression and decompression rate using a 2 GHz Pentium. If your sampling rate requirements are at lower sampling rates (lower than 2 Msamp/sec, for example), or if you have non-realtime (offline) compression requirements, please contact Samplify Systems at info@samplify.com to discuss a port of Samplify compression to your particular target environment. Thanks, Al Norm Dresner wrote: > > Since you've chosen to post this message in comp.arch.embedded, you are > obviously aware that most of us here don't use Windows [in fact most of the > readers of this NG don't even use Intel x86 architecture CPUs] -- you are > aware of it, aren't you??? > > Anyway, since you've chosen to advertise this in a newsgroup dedicated to a > very large variety of CPU architectures and operating systems, I'd like to > know when you'll have a generic version (preferably source code) available ? > > NormArticle: 79322
"Austin Lesea" <austin@xilinx.com> wrote in message news:cuvptt$baj6@cliff.xsj.xilinx.com... > Vaugn, > > Shell and pea game: no, you do not get the entire benefit of reduced C. The entire benefit would be 19% speed and dynamic power reduction. As I said, we get about 2/3 of that maximum benefit, since not all C is metal C, but most is. > > Also, not all layer dielectrics are Lo-K. For example, the clock tree is > near the top, where regular dielectric is used, isn't it? We use low-k to near the top of the metal stack. At the very top, where you're routing power and ground, you don't need (or even want it), since high capacitance on power and ground is beneficial (helps prevent ground bounce & vcc sag). The vast majority of the switching capacitance (clocks, routing, ALMs, MACs, etc.) is in metal surrounded by low-k. > At least, we evaluated both with, and without Lo-K devices (from the same > masks and fab), and were surprised to see only a 5% improvement. > > Did you do the same experiment? We were surprised. We simulated everything with and without low-K, and got the ~13% improvement I previously mentioned. I am also surprised you got only 5%. That is certainly well below mainstream for the industry -- if everyone were seeing such small gains, I doubt the fabs and semiconductor equipment vendors would be pumping billions into developing low-k (and next generation extra-low-k) dielectrics. Sounds like you may have used low-k for only a few metal layers, so perhaps that explains your disappointing experience. > Turns out, there is a lot more in the equations that just C. > > If it was just that simple, extracted simulations in spice would be > unneeded. This is backwards. As metal capacitance has become the dominant capacitance, extracting layouts to obtain all the metal parasitics before running SPICE has become essential to getting accurate answers. Go back enough process generations and this was less true -- you could write up your transistor-level schematic in a SPICE deck, simulate it with no thought of metal, and you wouldn't be that far off for most circuits, since transistor parasitics dominated. Now that metal dominates, you have to extract layouts to get the metal C or you get bad answers. Vaughn Betz Altera [v b e t z (at) altera.com]Article: 79323
Thanks for the replys. This application is cost sensitive and SP3 is the best choice for production but when the this design was made the SP3 was not easily available and customer is reluctant to use BGA packages (also because PCB costs). This statement in XAPP250's summary: "..With minor modifications, Clock and Data Recovery (CDR) is possible with Virtex-E and Spartan=99-IIE devices..." and since XC2S200E-6 is under this limits (I know it is barely bellow maximum) made me believe I could do it with this device I had in hands. If you believe I cannot do it I wont waste time trying and will ask customer to make a new PCB using SP3.Article: 79324
Hi, I had designed a simple PLB master and posted some questions on the news group. The thread message was titled "Designing a simple PLB Master using EDK 6.3i". The last message in the thread was 2/1/2005. Read it is to see if it helps in general (refer to the PLB PDF document that I referenced in the thread). Addressing your specific question, I have never dealt with the problem you are dealing with. Is the slave asking you to "retry" the request again? All the best, NN On 16 Feb 2005 mmkumar@gmail.com wrote: > Hi, > I am desging an master interface for 64-bit PLB.when i am not locking > the bus and if i get a Mn_rearbitrate from the slave ,and am > de-asserting and asserting the request after one clk.But it seems like > the arbiter is not arbitrating the request from the me(master) after it > got an M1_rearbitrate(never i get the bus , after that), how i can i > proceed further to do my data transfer. > > thanx, > mack. > >
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