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
Are the fsl() functions being invoked in the same task (after a context switch) or in a different task? If in a different task - are you enabling the MSR APU bits prior to the kernel being initialized? Global processor level initialization (such as MSR, caches and other core registers) should happen before xilkernel_main(). This will convey the user's intent regarding the processor state to the kernel and ensure that all subsequent task switches get the same MSR value. Vasanth "Andreas Hofmann" <ahofmann@ti.cs.uni-frankfurt.de> wrote in message news:eeri3h$1t2$1@tantalos.rbi.informatik.uni-frankfurt.de... > Hello, > > i'm trying to move data between the ppc405-core of a V4FX20 and a > microblaze. The ppc and the microblaze are connected via an FSL link: > > PPC-APU <-> FCB <-> FCB2FSL <-> FSL <-> MB > > To transfer data the putfsl()/getfsl() functions are used. > > The data transfer works flawlessly if the standalone BSP is used on the > PPC. If xilkernel is used on PPC and a task switch occurs between > enabling the APU and calling putfsl()/getfsl() an unknown-instruction > exception is generated. It looks like the MSR is not properly saved > and/or restored. > Is this the case or do i have to do a little more than just set bit 6 in > MSR? > > > Regards, > AndreasArticle: 109076
> but it uses verilog at such advanced level that is not supported > by Xilinx XST synthesis, e.g. it is only useable with Synplify > as synthesis tool It's about time Xilinx had full Verilog 2001 support really. What year is it? Still, on the plus side, if you do use Synplify, at least the rest of your design might work too ;-) Cheers, JonArticle: 109077
David Ashley <dash@nowhere.net.dont.email.me> wrote: >Nico Coesel wrote: >> All you need is a normal clock and a 90 degrees phase shifted clock. >> The whole clocking outside the fpga thing is unnecessary. If you place >> the output flipflops inside the IOBs and use an fddr in the IOB to >> replicate the internal clock, all signals connected to the DDR memory >> will have the same delay. > >But the DDR spec says the DQS strobe for data written to the >fpga must be center aligned. The DQS is in phase with the >DDR clock. That means the data must be put on the lines >1/2 of 1/2 of a clock cycle early for proper alignment. > >This requires a clock that is 270 degrees out of phase from the >DDR's clock. This is the clock used for the data lines going into >the DDR.. Yes. >I don't understand the "clocking outside the fpga" you mention. As AFAIK the opencores ddr controller uses some sort of scheme which routes the clock to the outside and pulls it back in again. This is totally unnecessary IMHO. >The fpga currently has one 50 mhz external clock source. I >run that through a DCM to make it 100 mhz. Then in order for >the DDR to work I need to use two more DCM's. One is used >to make the DDR clocks (positive and negative). The other is >used for everything else. For the DDR you'll need 2 DCMs: 1 to turn 50MHz into 100MHz and 1 to get a clock which is 90 degrees out of phase. fddrs have an internal inverter in their clock inputs so 1 clock to drive these is sufficient. Both DCMs can also be used to create a divided clock from each and 200MHz. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 109078
And you can probably run 12 picoblaze (or whatever Antti has) at 40 MIPS in XC3S200-FT256. I think it is better than 300 mhz single blackfin or PPC in terms of number of i/o, access speed of i/o..Article: 109079
"Gabor" <gabor@alacron.com> wrote: > >David Ashley wrote: >[snip] >> But the open cores DDR doesn't make use of the DQS strobe generated >> by the DDR device itself. I'm only trying to run at 100 mhz. In that >> case xilinx app notes say the timing is adequate so the DQS strobe isn't >> needed to capture data reliably. Maybe the timing would get easier if >> the logic made use of the DQS strobe from the DDR. >> > >I'm doing pretty much the same thing with Virtex 2 (similar >architecture >to Spartan 3) on a proprietary board. This board has a 66.66 MHz >clock that is doubled to run the DDR at 133 MHz (266 DDR). I >do not use the DQS inputs for sampling data. I did need to tweak >the delay in my DCM's to get reliable sampling. I did not use any >expensive test equipment for this, I just used the variable delay >mode of the DCM to run tests at various phases and centered >the final fixed value within the area that seemed to work. > >At 100 MHz I would expect the timing margins to be quite good >even in the slowest speed grade parts. I'm using Virtex 2 -5 >speed grade in my 133 MHz design. > >> I have a feeling adding some constraints would make the thing work >> with a single DCM. Unfortunately I have no clue what constraints to >> add, as I don't know what's going wrong (and don't know much about >> constraints writing anyway). >> > >The problem with a single DCM is that you need to make up >for phase differences in the board routing. Signals to the DDR >memory arrive there some prop. delay after they leave the FPGA. >At the memory end they need to meet setup and hold time to >the clock as it arrives at the memory, usually at the same >board routing delay as the clock. So if your clock and data/ >address/control outputs use the same internal clock, you >would need to use board routing or some other delay element >external to the FPGA to ensure hold time is met at the memory. All these problem go away if you drive the control signals at half the DDR clock frequency. This is not going to cost performance since all DDR commands need 2 clock cycles to execute anyway. The only signal that needs to be fast is CS (which also happens to be the least loaded line in a larger memory system). Clocking data into the memory uses DQS which has the same delay as the DQ lines (if your PCB layout is routed as it is supposed to be). >Then the data returning from the memory shows up 2 board >prop. delays from the driven clock, plus the clock to output >timing specified in the memory datasheet. So the sampling >point isn't exactly centered within the outgoing clock half- >period. So your sampling clock may need to be off by some >phase other than 90 degrees from the clock driving your >outputs. All of this is pretty hard to accomplish with one >DCM, IMHO. And just adding timing constraints without the >mechanism to meet them makes life miserable on the tools, >which usually fail miserably in response (they have only >internal routing delays to make up your requested timing). If you delay DQS by the IOBDELAY and use this signal to clock DQ (without IOBDELAY) into the IOB flipflops, then setup and hold timing should be met (with the proper constraints). But beware, there are severe limits on how the IOBs must be arranged and you may need to match the FPGA speed with the memory speed. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 109080
Antti <Antti.Lukats@xilant.com> wrote: > FPGA is not a MicroController? > ...or is it !? > > MicroFpga makes an FPGA YASC - Yet Another Soft Core. How thrilling. pete -- pete@fenelon.com "I once coaxed a dog into a library" - Tommy SaxondaleArticle: 109081
Pete Fenelon wrote: > YASC - Yet Another Soft Core. How thrilling. > > pete Good point. Any soft core needs to be compatible somehow otherwise what's the point. Not that this one isn't...I don't know. Does gcc work with it? Either linux or ucLinux support the cpu? Is it PIC, AVR, MIPS, ARM compatible? Too many "no"'s means forget it... -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 109082
Pete Fenelon schrieb: > Antti <Antti.Lukats@xilant.com> wrote: > > FPGA is not a MicroController? > > ...or is it !? > > > > MicroFpga makes an FPGA > > YASC - Yet Another Soft Core. How thrilling. > > pete > -- > pete@fenelon.com "I once coaxed a dog into a library" - Tommy Saxondale Pete, it's even far less thrilling, its not even another soft core :) I am far too lazy. So I am not inventing when there is no need. AnttiArticle: 109083
Nico Coesel wrote: > As AFAIK the opencores ddr controller uses some sort of scheme which > routes the clock to the outside and pulls it back in again. This is > totally unnecessary IMHO. Yep you're right, that was the feedback line for one of the DCM's. Current design works but has no feedback from the outside as you suggest. Original design was right on the edge as regards sampling the DDR's output data. > For the DDR you'll need 2 DCMs: 1 to turn 50MHz into 100MHz and 1 to > get a clock which is 90 degrees out of phase. fddrs have an internal > inverter in their clock inputs so 1 clock to drive these is > sufficient. You're exactly right. Also DCM -> DCM seems to work ok, however I'm ignoring the "locked" bit on the 50->100 DCM and the system only pays attention to the locked bit on the 2nd DCM. This is probably bad. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 109084
Austin Lesea schrieb: > Sumesh, > > I will look into your complaints. It hurts everyone if our parts are > presented poorly by a distributor on their demo pcbs. > > I am sorry for your experience with this board. > > If anyone else has had a poor experience with a pcb (any pcb from us, or > one of our authorized distributors), please let me know. > > I would prefer email to me directly. > > I will offer no excuses, as there are none: to showcase a new part, > only the best effort is acceptable. > > Austin Austin, I will be mailing you in private about the quality (of the boards and support). But I just received e-mail about: WTF is Digilent doing? namly the raised the price of the "Spartan 3E-1600 Board" from 199 USD to 295 !!!!!! IMHO that is not a good business policy. if the price tag was set as 199 then it should not go up by 50% the person who emailed me was about considering buying that board now he will not do that. I myself was almost thinking at the 199, at 295 NO WAY I am even considering. (I do have actually far too many Xilinx boards already at home). AnttiArticle: 109085
Hello, if my system is organized as the following
---------Microblaze-----lmb-----8k BRAM
|
Opb Bus
|
64k BRAM-----opb bus-----customized circuit
I initialized my opb bram with the following sentence.
float *y, *z;
y=(float *)(XPAR_OPB_BRAM_IF_CNTLR_1_BASEADDR+YBaseAddr);
z=(float *)(XPAR_OPB_BRAM_IF_CNTLR_1_BASEADDR+ZBaseAddr);
/* data initialization */
for(i=0;i<N;i++)
{
y[i] = i+1;
z[i+10] = i+2;
}
But when I do simulation, the above initialization process is very time
consuming. So I am wondering is there an easy way to do the OPBBRAM
initialization at the configuring time?
One way I think it is doable is to manually replace the configuration
of the OPB BRAM in the system_init.vhd file generated by XPS. But with
64kB BRAM, implemented as 32 ramb16_s1_s1. I need time to figure out
how the XPS store data there and fill them with my own data. And every
time when the application program changes I need to do this again.
It seems to me XPS only initialize the instruction memory with the
application program. Can it do the initialization of other BRAM when
simulation model is generated, eg, by providing some data file?
Thanks a lot
Article: 109086Alex wrote: > I'm running a Spartan3E (100e, vq100) with the VHDL below. > > It's connected to an LED display. The CLOCK_OUT, for some reason, is > bouncing before settling. When I connect an audio meter to the line, I > can hear it ringing on and off very quickly before settling back to > off. This is causing my DATA_OUT to be clocked many more times than > once. The VHDL below is a trimmed down version of what will be a more > complex project -- I'm just starting simple to assert that everything > works. > > I have the large divider on it so that I can visually see each byte > getting clocked onto the LED panel. The behavior I am seeing is the > entire panel filled with each byte (because of the bouncing CLOCK_OUT). > The panel should be counting across. > > > My CLOCK_OUT pin is defined as the following in my UCF file: > > NET "CLOCK_OUT" LOC = "P3" ; > > I have tried, to no success: > > NET "CLOCK_OUT" LOC = "P3" | PULLUP; > > > Thank you for any help! > > > entity driver is > Port ( CLOCK : in STD_LOGIC; > ACTIVE : in STD_LOGIC; > CLOCK_IN : in STD_LOGIC; > LATCH_IN : in STD_LOGIC; > DATA_IN : in STD_LOGIC_VECTOR (7 downto 0); > ADDRESS_IN : in STD_LOGIC_VECTOR (4 downto 0); > DATA_CLOCK_OUT : out STD_LOGIC; > CLOCK_OUT : out STD_LOGIC; > LATCH_OUT : out STD_LOGIC; > DATA_OUT : out STD_LOGIC_VECTOR (7 downto 0) ); > end driver; > > architecture Behavioral of driver is > signal mode : STD_LOGIC := '0'; > signal divider : STD_LOGIC_VECTOR(23 downto 0) := > "000000000000000000000000"; > signal output : STD_LOGIC_VECTOR(7 downto 0) := "00000000"; > begin > process( CLOCK ) > begin > if( rising_edge( CLOCK ) ) then > if divider="000000000000000000000000" then > if mode='0' then > CLOCK_OUT <= '0'; > LATCH_OUT <= '0'; > elsif mode='1' then > DATA_OUT <= output; > CLOCK_OUT <= '1'; > LATCH_OUT <= '1'; > output <= output + 1; > end if; > > mode <= not mode; > end if; > > divider <= divider + 1; > end if; > end process; > end Behavioral; It looks like "CLOCK", "LATCH_OUT", "DATA_OUT", "mode", and "output" only change when "divider" is all 0's. Also, your signals may not get initialized in the real hardware. It's best to initialize them when the hardware is reset. -Dave PollumArticle: 109087
Will it be available in Spartan2 or VirtexE? Antti wrote: > Pete Fenelon schrieb: > > > Antti <Antti.Lukats@xilant.com> wrote: > > > FPGA is not a MicroController? > > > ...or is it !? > > > > > > MicroFpga makes an FPGA > > > > YASC - Yet Another Soft Core. How thrilling. > > > > pete > > -- > > pete@fenelon.com "I once coaxed a dog into a library" - Tommy Saxondale > > Pete, > > it's even far less thrilling, its not even another soft core :) > I am far too lazy. So I am not inventing when there is no need. > > AnttiArticle: 109088
cathy schrieb:
> Hello, if my system is organized as the following
>
> ---------Microblaze-----lmb-----8k BRAM
> |
> Opb Bus
> |
> 64k BRAM-----opb bus-----customized circuit
>
>
> I initialized my opb bram with the following sentence.
> float *y, *z;
>
> y=(float *)(XPAR_OPB_BRAM_IF_CNTLR_1_BASEADDR+YBaseAddr);
> z=(float *)(XPAR_OPB_BRAM_IF_CNTLR_1_BASEADDR+ZBaseAddr);
>
> /* data initialization */
> for(i=0;i<N;i++)
> {
> y[i] = i+1;
> z[i+10] = i+2;
> }
>
> But when I do simulation, the above initialization process is very time
> consuming. So I am wondering is there an easy way to do the OPBBRAM
> initialization at the configuring time?
> One way I think it is doable is to manually replace the configuration
> of the OPB BRAM in the system_init.vhd file generated by XPS. But with
> 64kB BRAM, implemented as 32 ramb16_s1_s1. I need time to figure out
> how the XPS store data there and fill them with my own data. And every
> time when the application program changes I need to do this again.
> It seems to me XPS only initialize the instruction memory with the
> application program. Can it do the initialization of other BRAM when
> simulation model is generated, eg, by providing some data file?
>
> Thanks a lot
of course you can initialize BRAMs from file
I havent done that with multiply BRAM blocks being used but it is
defenetly
doable.
one way that DEFENETLY works (if all others fail)
is to create manually .BMM file with PLACED constraints
and add matching LOC's for the BRAMs into the UCF
but I hope XPS can handle multi BRAM inits also in more easy manner
Antti
Article: 109089Antti, Digilent is a business. They need to make money. I have no control over their pricing (or anyone else's pricing). Perhaps you should complain to Digilent? Austin Antti wrote: > Austin Lesea schrieb: > > >>Sumesh, >> >>I will look into your complaints. It hurts everyone if our parts are >>presented poorly by a distributor on their demo pcbs. >> >>I am sorry for your experience with this board. >> >>If anyone else has had a poor experience with a pcb (any pcb from us, or >>one of our authorized distributors), please let me know. >> >>I would prefer email to me directly. >> >>I will offer no excuses, as there are none: to showcase a new part, >>only the best effort is acceptable. >> >>Austin > > > Austin, > > I will be mailing you in private about the quality (of the boards and > support). > But I just received e-mail about: WTF is Digilent doing? > namly the raised the price of the "Spartan 3E-1600 Board" > > from 199 USD to 295 !!!!!! > > IMHO that is not a good business policy. if the price tag was set as > 199 then it should not go up by 50% > > the person who emailed me was about considering buying that board > now he will not do that. > > I myself was almost thinking at the 199, at 295 NO WAY I am even > considering. > (I do have actually far too many Xilinx boards already at home). > > Antti >Article: 109090
> of course you can initialize BRAMs from file > I havent done that with multiply BRAM blocks being used but it is > defenetly > doable. > Would you tell me how to do it in more detail? How the files look like and how to use it? Or some link to the guidance? Thanks a lot > one way that DEFENETLY works (if all others fail) > is to create manually .BMM file with PLACED constraints > and add matching LOC's for the BRAMs into the UCF > > but I hope XPS can handle multi BRAM inits also in more easy manner > > Antti I want to do the BRAM initialzation in simulation. The XPS generated system_init.bmm file automatically like this: opbBram64k/opbBram64k/ramb16_s1_s1_0 [31:31] ; opbBram64k/opbBram64k/ramb16_s1_s1_1 [30:30] ; opbBram64k/opbBram64k/ramb16_s1_s1_2 [29:29] ; ........................... opbBram64k/opbBram64k/ramb16_s1_s1_30 [1:1] ; opbBram64k/opbBram64k/ramb16_s1_s1_31 [0:0] ; the data is store in another file called system_init.vhd. And in this case, I need to split my each bit of my 32-bit data into different BRAM, so I need 32 different files to do that. Is that correct? Then I need to write another program to generated these files. That doable, but require some time. How do I give data in the .bmm file? Thanks a lotArticle: 109091
Derek Simmons wrote: > I'm just curious and it might not be applicable to application but did > you try targeting a Stratix II? If you did what kind of fMax's where > you able to achieve? Or just a Cyclone-II - the (currently) latest installment in Altera's low-cost offerings. If you're not supplying timing constraints, be sure to take the fitter out of its default Auto Fit mode, or it will simply give you _a_ possible solution with possibly horrible performance. Altera is boasting (some) performance advantage over Spartan-3, so here's a chance to see some real field feedback. Best regards, BenArticle: 109092
Hi, I have an ML403 board with EDK7.1i. When I try to connect with XMD to a ppc405 based design running at 300 MHz then the connexion does not seem to give the right information (when i read memory the data i get does not correspond at all to what i expected) although the connexion messages do not indicate any problem. Moreover when I download a bitstream containing the application (the very simple memory test for example in a system including DDR) the application keeps running and never stops. I do not have the same problem at 100 MHz speeds for the ppc405. Does anyone have an idea as to why I have such a behavior ? Best regards, JF HassonArticle: 109093
cathy schrieb: > > of course you can initialize BRAMs from file > > I havent done that with multiply BRAM blocks being used but it is > > defenetly > > doable. > > > Would you tell me how to do it in more detail? How the files look like > and how to use it? Or some link to the guidance? > Thanks a lot > > one way that DEFENETLY works (if all others fail) > > is to create manually .BMM file with PLACED constraints > > and add matching LOC's for the BRAMs into the UCF > > > > but I hope XPS can handle multi BRAM inits also in more easy manner > > > > Antti > I want to do the BRAM initialzation in simulation. The XPS generated > system_init.bmm file automatically like this: > opbBram64k/opbBram64k/ramb16_s1_s1_0 [31:31] ; > opbBram64k/opbBram64k/ramb16_s1_s1_1 [30:30] ; > opbBram64k/opbBram64k/ramb16_s1_s1_2 [29:29] ; > ........................... > opbBram64k/opbBram64k/ramb16_s1_s1_30 [1:1] ; > opbBram64k/opbBram64k/ramb16_s1_s1_31 [0:0] ; > the data is store in another file called system_init.vhd. > And in this case, I need to split my each bit of my 32-bit data into > different BRAM, so I need 32 different files to do that. Is that > correct? Then I need to write another program to generated these files. > That doable, but require some time. > How do I give data in the .bmm file? > > Thanks a lot look at data2mem options it can convert quite many different things of course the easiest is just to test in FPGA :) I am NEVER doing microblaze hdl sims. maybe I am forced todo them someday, but usually its easier to test in FPGA with XMD and ChipScope then doing sims AnttiArticle: 109094
Hi Andreas, There is something you could try: It is very likely caused due to missing libstdc++.so.5. Suse 10 ships with libstdc++.so.6. If you install libstdc++ compatibility package (which has libstdc++.so.5) on your system the design should work. The compatibility package can be found here: http://www.novell.com/products/linuxpackages/suselinux/compat-libstdc++.html Thanks Duth Duth wrote: > Hi Andreas/Roger, > > I am afraid that SuSe is not an officially supported Linux distribution > by Xilinx currently. We are evaluating the need for support of SuSe for > future releases of Xilinx Tools though. Right now RH3.0 and 4.0 are the > only oficiallly supported Linux Distributions. if you would like to > request the priority raised on the SuSe support, please contact your > nearest FAE and let them know. > > Thanks > Duth > > Roger wrote: > > "gauckler" <gauckler@fh-furtwangen.de> wrote in message > > news:1158562165.368801.101410@i3g2000cwc.googlegroups.com... > > > Hi, > > > > > > i tried to simulate a small vhdl design with xilinx ISE (8.1 - 8.2 > > > spxx, Webpack or foundation) running SuSE 10.1 linux, unfortunately > > > there is an error. Because the VHDL code simulates with SuSE 9.2 I > > > assume the code is fine and there are no spaces in the file path. > > > > > > Started : "Check Syntax". > > > Running vhpcomp > > > Compiling vhdl file "/home/PBuser2/parity/parity.vhd" in Library > > > isim_temp. > > > Entity <parity> compiled. > > > Entity <parity> (Architecture <behavior>) compiled. > > > Compiling vhdl file "/home/PBuser2/parity/tb_parity.vhd" in Library > > > isim_temp. > > > Entity <tb_parity_vhd> compiled. > > > Entity <tb_parity_vhd> (Architecture <behavior>) compiled. > > > Parsing "tb_parity_vhd_stx.prj": 0.03 > > > > > > Process "Check Syntax" completed successfully > > > > > > Running Fuse ... > > > Parsing "tb_parity_vhd_beh.prj": 0.00 > > > Building tb_parity_vhd_isim_beh.exe > > > ERROR:Simulator:222 - Generated C++ compilation was unsuccessful > > > > > > Has anybody simulated ISE isim under SuSE 10.1. Any hint is > > > appreciated. > > > > > > Andreas > > > > > > > Same thing with just ISE - no solution. Sorry. This really is something > > Xilinx should be sorting. > > > > Rog.Article: 109095
Ben Twijnstra wrote: > Derek Simmons wrote: > > > I'm just curious and it might not be applicable to application but did > > you try targeting a Stratix II? If you did what kind of fMax's where > > you able to achieve? > > Or just a Cyclone-II - the (currently) latest installment in Altera's > low-cost offerings. If you're not supplying timing constraints, be sure to > take the fitter out of its default Auto Fit mode, or it will simply give > you _a_ possible solution with possibly horrible performance. > > Altera is boasting (some) performance advantage over Spartan-3, so here's a > chance to see some real field feedback. > > Best regards, > > > > Ben If you are concerned with raw speed, it definitely pays to play with the Quartus fitter settings. I recently completed a redesign of the vautomation v8 uRISC (now Arclite) 8-bit CPU. I tested it for size by compiling it alone, and with default fitter settings, achieved about 80 MHz. By pushing the fitter a bit harder, I was able to achieve 113MHz. Now, using the same settings, I'm getting my entire SoC design to operate at 80MHz. This was in a cyclone II, and my CPU implementation uses purposefully generic behavioral VHDL. I could probably have gotten better results using Altera primitives, but I hate being tied down to a single vendor. Note, my system frequency was 75MHz, so I pushed the fitter to give me timing margin for when I added the rest of the logic. I haven't done as much with the Xilinx ISE, but I would imagine the situation is pretty similar.Article: 109096
Johannes, Lattice's current software, ispLEVER 6.0 does offer the ability to reinitialize your memory contents without recompiling your design. Using the Memory Initialization tool, accessed from the tools menu, a new, or modified memory file .mem can be written to the designs database file .ncd. After this is done all that needs to be rerun is the 'Generate Bitstream Data' process. This feature is only available for use on memory blocks that are implemented in the devices EBR blocks and created using the software's IPExpress module generation tool.Article: 109097
Assuming it must be free + open source, does anyone have any recommendations? 32 bit minimum. I was looking at the plasma on opencores. Has anyone done a uclinux port or thought of doing one? Conversely if someone wants a uclinux port to plasma I'll do it for $$$. :) -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 109098
David Ashley schrieb: > Assuming it must be free + open source, does anyone have > any recommendations? 32 bit minimum. I was looking > at the plasma on opencores. Has anyone done a uclinux > port or thought of doing one? Conversely if someone wants > a uclinux port to plasma I'll do it for $$$. :) > > -Dave > > > -- > David Ashley http://www.xdr.com/dash > Embedded linux, device drivers, system architecture David, how much $$$ are we talking about? I am looking for open-source core with uclinux, but OR1K is too large AnttiArticle: 109099
Peter Kampmann wrote: > Hi everyone, > > I've build a custom peripheral and now want to insert new Data into my > Design via the PowerPC every clock cycle. > > My Problem is: how to resolve the next clock cycle with the PowerPC? > I've read the Tutorial by Richard Griffin, who suggests to set an > additional register that counts backwards a given number, to > synchronize with your peripheral. > > As I want to use the clock cycle for the next input, I set the clock > signal to a bit of my output registers (using OPB Bus with User Logic > S/W Register Support on Virtex 2 Pro). I now tried to detect the rising > and falling edge of the clock by reading from the Register via the > <PERIPHERAL>_mReadReg(....) command. > > But unfortunately, I never get the rising edge of the clock :( > The PowerPC, on which the C++ Code that reads the register, runs with > 300 Mhz. The synthesis of my custom peripheral told me a Frequency of > about 150 Mhz. > The custom peripheral is attached to the sys_clk_s. > > I assume that the PowerPC should run significantly faster than the > peripheral, but it seems that both run with the same clock. > > Hope I have described my problem clearly. > > Thanks for any help! > > Regards, > Peter > The easiest way would be to have the PPC stuff the data into a FIFO and your hardware design take it out once each clock cycle. That said, I don't believe the buss for the PPC runs at 300 MHz, I think that is just the core processor speed. You might not have enough horsepower in the PPC to keep up with a 150 MHz clock, depending on the processing per sample and size of the data words relative to the bus width.
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