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
Sorry, I forgot to make reference to this part of ur reply: > > I can only transmit through the board data at a maximum rate of 1Mbps. > > Anything more than that is lost. > > You mean "to the board", not "through", yes ? The application I made for the board, receives UDP data from a source PC, and retransmits them to a destination PC.Article: 122801
Andreas Gauckler wrote: > Hello, > > I try to communicate with a Digilent S3- Board via USB-Module 2 using linux > (libusb). Has anybody successfully transmitted or received data this way > (the win32 way works) ? Are you saying that you figured out to use libusb with the standard firmware that comes with the USB2 module from digilent? [...] Are you trying to use the firmware that comes with the board or do you want to use a new firmware? I had been in a discussion about that on the opencores mailing list about a year ago: http://www.opencores.org/forums/openrisc/2006/07/002795 After that I found usbp, a python extension to libusb and tried to use it: http://sourceforge.net/projects/usbp/ However, the extension only had been done for windows and I did not look into getting it to go under Linux, so my interest died off and I am still at the same point as last year. What I learned is that usbp has an own firmware for the Cypress USB chip that also seems to run on the digilent usb2 board, allowing it to run faster than with the original firmware. Cheers, GuenterArticle: 122802
Guru <ales.gorkic@email.si> writes:
>The mch_opb_sdram controller is the same shit. He would only get a
>bunch of stuff that he does not need and low bandwidth.
I second that...
In the early stages of writing my own DDR controller, I thought I can get a bit
of inspiration from mch_opb_ddr. That was wrong. I've never seen such a crude
VHDL coding style. To me it looks like the result of a class of VHDL beginners.
Lots of asynchronous processes with huge sensitivity lists, component
instantiations that make the dataflow more mysterious than obvious, etc. When
counting all the required modules (ipif*, etc.) it gives a 200 page book.
Now I have my own small (~2000 lines including Microblaze interface) controller,
with open row management for all banks, burst support (>350MB/s from a
16Bit/133MHz DDR) and 5 independent ports with local burst data caches and an
easy command like interface... The size is about the same as the mch_opb_ddr. The
Microblaze R/W memory performance also nearly doubled, and there are still some
unnecessary latencies left for later optimization.
So my recommendation is the same: Write the controller on your own. You can
adopt its interface exactly to your needs and avoid unnecessary protocol
conversion cycles. It can only get better...
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Article: 122803On Aug 6, 4:11 pm, austin <aus...@xilinx.com> wrote: > Dan, > > Connecting, and disconnecting cables, or headers, of parts mounted on > boards is not usually an ESD issue. > > ESD is thousands of volts, from static electricity accumulation (usually > on your person). Usually holding each assembly in your hands is enough > to insure the potential difference between them is small (your skin and > body neutralizes any charge difference between the two while you hold > them). This does mean that you use both hands, so the two assemblies > are neutral to each other. > > Sounds like you are concerned about "hot plugging" or connecting and > disconnecting live (or will be live soon) interfaces. > > So, which is it? Damage from very high static voltages? Or damage from > voltages within the normal operating range of the device when inserted > live into a system? > > As far as Xilinx FPGAs go, we publish our human body model ESD and > machine model ESD specifications, and we also have no problem with live > insertion (power on), as long as ground connects first, before an IO > connects. > > The reason why we suggest that grounds mate first, is that the ground > provides the return path for any transients, and the self-protecting IO > structures are better at protecting themselves if they share a ground. > > Austin > > > > EEngineer wrote: > > I need to connect the Xilinx ML402 board to the 3.3V CMOS chip. I am > > concerned about the ESD that could burn the CMOS chip. > > > I am concerned about the possibility of the ESD when CMOS is being > > connected or disconnected from the FPGA board's header, even though I > > would do it when both devices are turned off. I know that this depends > > on the chip itself, but I wonder if there are any general precautions > > that I could follow that would make this steps less hazardous? Is it > > more safe to set all the FPGA board's outputs to high impedance state > > once the task has been done before turning the board off? > > > The complete loop: > > - FPGA creates control signals, including clock, that are sent through > > the board's header to the 3.3V CMOS chip. > > - CMOS chip generates some data on its outputs that are connected to > > the FPGA board's header. > > > Thanks, > > -Dan- Hide quoted text - > > - Show quoted text - Good that FPGA ML402 board with Virtex 4 is safe, but how about this boards influence onto CMOS prototype chip - I am more concerned about it because CMOS chip cost is 20x higher then the FPGA board! It is 3.3V TSMC .35um technology.Article: 122804
>"commone" <dechenxu@yahoo.com.cn> wrote in message >news:DvmdnUUttI-I-CXbRVn_vgA@giganews.com... >> Hi Symon, >> Check out this link: >> http://focus.ti.com/lit/ug/spru889/spru889.pdf >> >> The design example on page 51 tells me how to design a Pi filter for >> Fig4-14. But now I try to design a filter as fig4-16. Then what kind of >> bandwidth should I choose? >> >> Thanks >> Leon, >> >Hi Leon, >That stuff in Fig4-14 looks dodgy at first glance, I wouldn't do that >myself. > >Anyway, I digress. For a power supply you would ideally require a very low >bandwidth. After all, passing DC is the requirement. You need to decide what >noise on the power supply you want to keep from your IC power. Also, the >filter will prevent noise from the IC switching its supply current from >getting back to the main power supply. > >For example, if you have a switching power supply going at (say) 1MHz, you >might want to filter that noise out. BTW., Ferrites are not always much use >at lower frequencies, you might need a 'proper' power inductor. >HTH., Syms. > > > Hi Symon, You are right. For low frequency, there is a Pi filter in the former document(Fig6-9). You said that "For a power supply you would ideally require a very low bandwidth. After all, passing DC is the requirement.". But IMO, for a digital IC, such as FPGA, DSP, on every clock edge, there will be a small or big load change for VDD/VCC pins so the current from power supply change accordingly. If that is right, the current needed by the digital IC will have a relatively big bandwidth. These high frequency components is the high frequency noise for the noise sensitive circuits and we should design a filter to prevent them from going outside. If the bandwidth of the filter is too low, I am not sure if the digital IC could be satisfied; otherwise, if the bandwidth is too big, the noise will not be controlled effectively. How to deal with this problem? Leon,Article: 122805
On Aug 7, 5:38 am, dkarch...@gmail.com wrote: > On 6 Aug, 08:13, "X.Y." <Xieyu1...@gmail.com> wrote: > > > > > > > I use Cyclone II to implement image processing. There are a CMOS image > > sensor, a FPGA chip, and a SRAM on my board. I meet a new problem when > > I try to optimize my design. In my old instance, I use the same clock > > when image capture (storage), image display, and image processing. > > This clock, which is named "pclk", has a frequency of 24MHz. It is > > slow. The frequency of image capture and display cannot be changed > > because of the requirement of other device. So I want to increase the > > frequency of image processing. It involves SRAM reading, writing, and > > data processing. I use a PLL to acquire a clock of 72MHz. This is the > > problem. SRAM will also be read when image capture, and written when > > display. That means the clock, the address bus and data bus will be > > switched between the state of image capture/display and image process. > > Actually, I use two blocks: one for image capture/display and another > > for image process. And I use BUS MUX to switch address bus and data > > bus. Meanwhile, I use LPM MUX to switch the two clock of different > > frequency. Unfortunately, the instance does not meet timing. In Timing > > Analyzer Summary, it reports, Clock setup: 'pclk' has a slack of > > -4.152ns and Clock hold: 'pclk' has a slack of -4.216ns. What should I > > do to solve this problem? > > > Best Regards, > > X.Y. > > Assuming you are using the Classic Timing Analyzer, make sure you have > a CUT assignment between the two clock domains. In the QSF, you want > to see something like: > > set_instance_assignment -from pclk -to <your pll clock name> - > name CUT ON > set_intance_assignment -from <your pll clock name> -to pclk -name > CUT ON > > You can make these assignments using the Assignment Editor. > > BTW, clock muxing is something the new TimeQuest Timing Analyzer does > very well. Here is an example of how to describe this in an SDC for > TimeQuest: > > http://www.altera.com/support/examples/timequest/exm-tq-clock-mux.html > > Hope this helps. > > -David Karchmer > Altera- Hide quoted text - > > - Show quoted text - Thanks for your reply! I use Classic Timing Analyzer. I want to try the CUT assignment. Unfortunately, I meet new problem. I right-click on the pclk pin and select locate in assignment editor. Then I select CUT Timing Path in the "assignment name" category and select the pll clock name in the "from" category. After that, I click save icon. Curiously, what I just assigned disappears. I open the QSF file, there is no my CUT assignment. How can I save my constraint setting? Best Regards. X.Y.Article: 122806
"commone" <dechenxu@yahoo.com.cn> wrote in message news:QfKdnc8d_4bwGyXbRVn_vgA@giganews.com... > > You said that "For a power supply you would ideally require a very low > bandwidth. After all, passing DC is the requirement.". > But IMO, for a digital IC, such as FPGA, DSP, on every clock edge, there > will be a small or big load change for VDD/VCC pins so the current from > power supply change accordingly. > > If that is right, the current needed by the digital IC will have a > relatively big bandwidth. These high frequency components is the high > frequency noise for the noise sensitive circuits and we should design a > filter to prevent them from going outside. > Hi Leon, OK, the PI filter is such that the right hand leg, the capacitor, has a very low impedance and a wide bandwidth. So this provides the high frequency current you need to power the IC. The pass element, the inductor or ferrite, allows DC through to keep this cap charged, but prevents HF noise from passing. Cheers, Syms.Article: 122807
ryufrank@hotmail.com wrote: > Sorry, I forgot to make reference to this part of ur reply: > >>> I can only transmit through the board data at a maximum rate of 1Mbps. >>> Anything more than that is lost. >> You mean "to the board", not "through", yes ? > > > The application I made for the board, receives UDP data from a source > PC, and retransmits them to a destination PC. > You could do that with just hardware, no need for a microblaze. SylvainArticle: 122808
On Aug 7, 10:14 am, ryufr...@hotmail.com wrote: > Sorry, I forgot to make reference to this part of ur reply: > > > > I can only transmit through the board data at a maximum rate of 1Mbps. > > > Anything more than that is lost. > > > You mean "to the board", not "through", yes ? > > The application I made for the board, receives UDP data from a source > PC, and retransmits them to a destination PC. Without "re-designing", you're biggest speed increase will be increasing your receive buffer size. Odds are you are probably just overrunning your receive queue. The V4FX temac has support for gathering these statistics. Complete w/ the PLB temac, you should be able to read out the registers from your software to see what's going on. If it follows what you posted, your design should be adequate to achieve a much higher speed than you have. I have a V4FX60-10 w/ the PowerPC running at 100MHz and using the MPMC2 w/ the CDMAC. With this I am able to achieve speeds >100Mb/s. (don't know about 1000Mb yet, haven't pushed it that far). -- MikeArticle: 122809
"EEngineer" <maricic@gmail.com> wrote in message news:1186497646.665903.202780@w3g2000hsg.googlegroups.com... > > Good that FPGA ML402 board with Virtex 4 is safe, but how about this > boards influence onto CMOS prototype chip - I am more concerned about > it because CMOS chip cost is 20x higher then the FPGA board! It is > 3.3V TSMC .35um technology. > Disconnecting won't be a problem. When you connect the boards together, do as Austin says and make sure the grounds connect first. Alternatively, wear a earthing strap, or just touch a nearby PC case, and connect the grounds together with your sweaty fingers. (This is why electronic engineers always shake hands before exchanging boards! Of course, if you're swapping boards with an atractive engineer (yeah, right!!) french kissing provides a better contact.) HTH., Syms. xxArticle: 122810
EEngineer, -snip- > Good that FPGA ML402 board with Virtex 4 is safe, but how about this > boards influence onto CMOS prototype chip - I am more concerned about > it because CMOS chip cost is 20x higher then the FPGA board! It is > 3.3V TSMC .35um technology. If this is a custom chip manufactured by TSMC, I have no idea how sensitive it is to ESD or any other electrical stress. That would depend on how the IC designers chose to do their ESD protection, and how they protected their output from damage when shorted to ground or Vcc. The ML402 board outputs are connected to the Virtex 4 chip, so depending on how you have the Vcco banks powered and how the device is configured, these IOs will either be; ground, logic high, or tristate. If the ML402 is not powered, all IOs look like a diode from the IP pin to Vcco, and a diode from ground to the IO pin. AT power ON, before configuration, all IOs are tristate. If the external CMOS IC is powered, and the ML402 is not, then the external IC sees the diodes to Vcco of the Virtex 4 bank (if they are outputs). Since you suggest to power both down, connect, and power both up, I don't see any issues with that. If you touch both the ML402 and the external CMOS chip, then their potential is equal, and no zap will occur when they connect to each other. Make sure that you work on an ESD conducting work surface, and wear a wrist strap connected to that surface (so you, the parts, the boards, the bench, are all at the same potential. If the IC designers did their job properly, and used TSMNC's foundry ESD protection cells, then you should have no worries at all. But, you should always use the ESD mat, and wrist strap anyway (just good practice). AustinArticle: 122811
On Aug 7, 4:03 pm, morphiend <morphi...@gmail.com> wrote: > On Aug 7, 10:14 am, ryufr...@hotmail.com wrote: > > > Sorry, I forgot to make reference to this part of ur reply: > > > > > I can only transmit through the board data at a maximum rate of 1Mbps. > > > > Anything more than that is lost. > > > > You mean "to the board", not "through", yes ? > > > The application I made for the board, receives UDP data from a source > > PC, and retransmits them to a destination PC. > > Without "re-designing", you're biggest speed increase will be > increasing your receive buffer size. Odds are you are probably just > overrunning your receive queue. The V4FX temac has support for > gathering these statistics. Complete w/ the PLB temac, you should be > able to read out the registers from your software to see what's going > on. If it follows what you posted, your design should be adequate to > achieve a much higher speed than you have. > > I have a V4FX60-10 w/ the PowerPC running at 100MHz and using the > MPMC2 w/ the CDMAC. With this I am able to achieve speeds >100Mb/s. > (don't know about 1000Mb yet, haven't pushed it that far). > > -- Mike Thank you for the reply. Just wanted yo clarify that I'm using the PPC processor at 100MHz, not a microblaze. It would be great if I could achieve such speed as your V4FX60 Mike, but I am out of luck (and skills, and time) :) I will try to play around with the buffer size, but as I recall I have already tried that with no big difference on the throughput. What makes me curious, is the maximum throughput I get is EXACTLY 1Mbps whatever I do. Could that be somekind of limitation implemented in the original example project's architecture?Article: 122812
> Thank you for your reply PFC. > Really helpful information. You're welcome ;) > I forgot to mention some information about my application, > It's using UDP, with a Gigabit Ethernet controller and Xilinx's > Microkernel (XMK). > > I knew that lwip and XMK were going to cause me delays, but I never > expected to be such great! > > The application I made for the board, receives UDP data from a source > PC, and retransmits them to a destination PC. Well, using a TCP stack and OS (like ucLinux for MicroBlaze, I don't know about XMK), adds a lot of complexity. Recently I looked into the Atmel AVR32 CPU with Linux ; this small CPU is very nice but it only does 2 MBytes/s on Ethernet (1 Mbyte/s on full duplex) with Linux. This is very good for this kind of embedded CPU. Basically, from the kernel sources, Linux does this : - Ethernet MAC uses DMA to copy the received packet to RAM ring buffer The DMA engine is very smart and supports a linked list of buffers. So, here, a compromise can be made : - either use 1.5kB buffers, which can hold a full packet, but waste space for small packets - or use several small buffers per packets (wastes less space, but needs a copy). This is what is done in the driver. - Allocating a SKB (Socket Buffer) for the full packet and copy the packet into it - UDP Checksum computation and verification - Going through the TCP stack (possibly one more copy) - Copying the packet data to user space - Application manipulates the packet and sends it - Copy packet from user space to skb in kernel - Build Ethernet and UDP headers - Compute UDP checksum - Queue skb for DMA send - DMA copy to MAC So you have 2 DMA copies (which is the minimum), plus at least 4 processor copies, which obliterate your performance. An optimum configuration for an UDP forwarder would be, without OS : - Have a pool of buffers - DMA write received packet to a buffer - CPU examines packet, messes with headers, does its thing - DMA to MAC for send This is zero copy and much faster, but you can't do this with an OS unless you really hack the drivers, TCP stack, and run without separate user/kernelmemory spaces. > Unfortunately there is no time for me to redesign the application to > achieve a good throughput, but I have learnt my lesson. Is this for a school project ? You also have to consider that MicroBlaze only runs at maximum speed when code and data come from LMB BRAM or I/D Cache. Executing code from SDRAM, or loading data from SDRAM, is HUMONGOUSLY SLOW if you use plain opb_sdram without cache links, you get something like 15 cycles per access, so your 50 MHz CPU becomes slower than some 8 bit dinosaur from 1980. And a large OS and TCP stack does not fit in fast BRAM or cache, plus it's full of branches/tests which kill the cache prefetching. If you want to handle 1 Gbps with your Virtex-4, at full throttle, keep in mind that with 1024 bytes per packet, this is more than 100.000 packets per second ! 10 microseconds per packet ! A Core 2 CPU will process a few tens of thousands instructions in 10 microseconds, but your 50 MHz Microblaze will only have about 500 cycles to process a packet. You can't do a lot of things in 500 cycles... especially with 12-15 cycle SDRAM access latency... That's why routers like WRT54G can afford to use Linux, because a 200 MHz ARM CPU can handle the very slow speeds of WiFi, but all the 10$ fast Ethernet switches on the market are basically just a chip with a hardware packet processing engine and a slow microcontroller which only has to tell the hardware "send the packet to port #2". I put my UDP code, and all the MAC driver code, in a BRAM block sitting on the LMB, with 1 cycle access time ; I could do this because it is so small ; a full TCP stack would never fit.Article: 122813
> Now I have my own small (~2000 lines including Microblaze interface) > controller, > with open row management for all banks, burst support (>350MB/s from a > 16Bit/133MHz DDR) and 5 independent ports with local burst data caches > and an > easy command like interface... The size is about the same as the > mch_opb_ddr. The > Microblaze R/W memory performance also nearly doubled, and there are > still some > unnecessary latencies left for later optimization. Would there be any remote possibility of imagining that you might some day consider the idea of putting this on OpenCores ? PS : I read your homepage, quite interesting ! I see you do home soldering of BGAs. Since you're in Europe like me, can you point me to a PCB prototyping fab that can handle the PCB tolerances needed for BGA escape routing ? PCB-POOL cannot...Article: 122814
"Symon" <symon_brewer@hotmail.com> wrote in message news:f9a16q$foi$1@aioe.org... > "commone" <dechenxu@yahoo.com.cn> wrote in message > news:QfKdnc8d_4bwGyXbRVn_vgA@giganews.com... >> >> You said that "For a power supply you would ideally require a very low >> bandwidth. After all, passing DC is the requirement.". >> But IMO, for a digital IC, such as FPGA, DSP, on every clock edge, there >> will be a small or big load change for VDD/VCC pins so the current from >> power supply change accordingly. >> >> If that is right, the current needed by the digital IC will have a >> relatively big bandwidth. These high frequency components is the high >> frequency noise for the noise sensitive circuits and we should design a >> filter to prevent them from going outside. >> > Hi Leon, > OK, the PI filter is such that the right hand leg, the capacitor, has a > very low impedance and a wide bandwidth. So this provides the high > frequency current you need to power the IC. The pass element, the inductor > or ferrite, allows DC through to keep this cap charged, but prevents HF > noise from passing. > Cheers, Syms. Besides, you're looking at filtering the PLL supply pins. The arguement about large load changes on each clock edge is valid for general digital circuits but not for the PLL supply. The PLL current should be significantly more smooth and would do very well with a low frequency cutoff. - John_HArticle: 122815
> It would be great if I could achieve such speed as your V4FX60 Mike,
> but I am out of luck (and skills, and time) :)
> I will try to play around with the buffer size, but as I recall I have=
> already tried that with no big difference on the throughput.
Hint :
Try it with different packet sizes, at constant throughput, ie. lots of=
=
small packets versus less packets, but bigger. So, you can measure two =
different things : the time it takes to process a packet (independent of=
=
length), and the time it takes to handle the data in it (which depends o=
n =
length).
> What makes me curious, is the maximum throughput I get is EXACTLY
> 1Mbps whatever I do. Could that be somekind of limitation implemented
> in the original example project's architecture?
Would you by any chance use a timer as an interrupt source, instead of =
=
the MAC "I received a packet" interrupt ? (check your interrupt wiring..=
.) =
Can your interrupt process ALL the pending packets ?
Hint : since all your processing will probably be in an interrupt =
handler, run a simple free CPU time performance meter in the non-interru=
pt =
code path (main() function).
I did it this way :
I know on an idle system, microblaze can process N iterations per secon=
d =
of a simple for () { i +=3D 1 }. I use a timer, and see how many iterati=
ons =
are actually done in one second, and print it on the serial port. So, I =
=
can see how much time is spent in the interrupt handler, in real time. I=
f =
I nuke it with too many 1 byte packets, it never gets out of the MAC =
interrupt handler, and it stops displaying the free CPU percentage.
Article: 122816All, We are desperately in need of EDK 8.1 for programming Xilinx Virtex-II MK325 . The disk we had is lost. Xilinx and its distributors NuHorizon or Avnet do not stock or sell 8.1 anymore sinc 9.1 has become available. The only sources are the illegal websites that sell you a crack and keygen etc. Is there any reliable source out there that someone has tried successfully. If any of you have a source we could download from that will be fantastic. Thanks in advance EchoArticle: 122817
Have you actually contacted Xilinx? They have version back to the very early days of FPGAs. "echo" <rukrimo@hotmail.com> wrote in message news:gbKdnVKQ1fkgIiXbnZ2dnUVZ_sytnZ2d@giganews.com... > All, > We are desperately in need of EDK 8.1 for programming Xilinx Virtex-II > MK325 . The disk we had is lost. Xilinx and its distributors NuHorizon or > Avnet do not stock or sell 8.1 anymore sinc 9.1 has become available. The > only sources are the illegal websites that sell you a crack and keygen > etc. Is there any reliable source out there that someone has tried > successfully. If any of you have a source we could download from that will > be fantastic. Thanks in advance > EchoArticle: 122818
I've hit a brick wall with this. I just can't figure out what I'm
doing wrong, or not doing right!
I just want to generate an interrupt when the pushbutton (PB) is
pressed. This is the only interrupt so far, but I'm using INTC
because I want to expand this soon.
The MHS file has:
BEGIN opb_intc
PARAMETER INSTANCE = opb_intc_0
PARAMETER HW_VER = 1.00.c
PARAMETER C_BASEADDR = 0x41200000
PARAMETER C_HIGHADDR = 0x4120ffff
BUS_INTERFACE SOPB = mb_opb
PORT Irq = Interrupt
PORT Intr = Push_Buttons_1Bit_IP2INTC_Irpt
END
BEGIN opb_gpio
PARAMETER INSTANCE = Push_Buttons_1Bit
PARAMETER HW_VER = 3.01.b
PARAMETER C_INTERRUPT_PRESENT = 1
PARAMETER C_GPIO_WIDTH = 1
PARAMETER C_IS_DUAL = 0
PARAMETER C_ALL_INPUTS = 1
PARAMETER C_IS_BIDIR = 0
PARAMETER C_BASEADDR = 0x40040000
PARAMETER C_HIGHADDR = 0x4004ffff
BUS_INTERFACE SOPB = mb_opb
PORT OPB_Clk = sys_clk_s
PORT IP2INTC_Irpt = Push_Buttons_1Bit_IP2INTC_Irpt
PORT GPIO_in = fpga_0_Push_Buttons_1Bit_GPIO_in
END
BEGIN microblaze
(snip)
PORT Interrupt = Interrupt
(snip)
END
This is my code:
microblaze_enable_interrupts();
/* Register the UART interrupt handler in the vector table */
XIntc_RegisterHandler(XPAR_OPB_INTC_0_BASEADDR,XPAR_OPB_INTC_0_PUSH_BUTTONS_1BIT_IP2INTC_IRPT_INTR,
(XInterruptHandler)pb_int_handler,(void
*)XPAR_PUSH_BUTTONS_1BIT_BASEADDR);
/* Start the interrupt controller */
XIntc_mMasterEnable(XPAR_OPB_INTC_0_BASEADDR);
/* Enable PB interrupt requests in the interrupt controller */
XIntc_mEnableIntr(XPAR_OPB_INTC_0_BASEADDR,XPAR_PUSH_BUTTONS_1BIT_IP2INTC_IRPT_MASK);
/* Enable PB interrupts */
XGpio_InterruptGlobalEnable(XPAR_PUSH_BUTTONS_1BIT_BASEADDR);
XGpio_InterruptEnable(XPAR_PUSH_BUTTONS_1BIT_BASEADDR,
XPAR_PUSH_BUTTONS_1BIT_IP2INTC_IRPT_MASK);
/* Wait for interrupts */
while (1){
if (num_interrupts >= 1){
xil_printf("-- Number of interrupts received : %x \n\r",
num_interrupts);
}
When debugging I can see that the IE bit in the MSR gets set. The
code hangs on
XGpio_InterruptGlobalEnable(XPAR_PUSH_BUTTONS_1BIT_BASEADDR);
The function in question from xgpio_intr.c:
void XGpio_InterruptGlobalEnable(XGpio *InstancePtr)
{
XASSERT_VOID(InstancePtr != XNULL);
XASSERT_VOID(InstancePtr->IsReady == XCOMPONENT_IS_READY);
XASSERT_VOID(InstancePtr->InterruptPresent == XTRUE);
XIIF_V123B_GINTR_ENABLE(InstancePtr->BaseAddress +
XGPIO_IPIF_OFFSET);
}
Any help greatly appreciated.
Article: 122819
In article <op.two6ceq5cigqcu@apollo13>,
PFC <lists@peufeu.com> writes:
|> Would there be any remote possibility of imagining that you might some
|> day consider the idea of putting this on OpenCores ?
It's a paid job, but I will consider it.
|> PS : I read your homepage, quite interesting ! I see you do home
|> soldering of BGAs.
Unfortunately, this system doesn't work with lead free anymore. The 40 deg
higher melting point is enough to ruin the PCB :-(
|> Since you're in Europe like me, can you point me to a PCB prototyping fab
|> that can handle the PCB tolerances needed for BGA escape routing ?
|> PCB-POOL cannot...
Ask them about about a special offer. I had 5 PCBs, 4 layer, 28*12cm each. It was
cheaper than in the pool... About 5 years ago, they tolerated 0.13/0.13mm in the
pool setup.
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Article: 122820
On 7 Aug, 07:51, "X.Y." <Xieyu1...@gmail.com> wrote:
> On Aug 7, 5:38 am, dkarch...@gmail.com wrote:
>
>
>
>
>
> > On 6 Aug, 08:13, "X.Y." <Xieyu1...@gmail.com> wrote:
>
> > > I use Cyclone II to implement image processing. There are a CMOS image
> > > sensor, a FPGA chip, and a SRAM on my board. I meet a new problem when
> > > I try to optimize my design. In my old instance, I use the same clock
> > > when image capture (storage), image display, and image processing.
> > > This clock, which is named "pclk", has a frequency of 24MHz. It is
> > > slow. The frequency of image capture and display cannot be changed
> > > because of the requirement of other device. So I want to increase the
> > > frequency of image processing. It involves SRAM reading, writing, and
> > > data processing. I use a PLL to acquire a clock of 72MHz. This is the
> > > problem. SRAM will also be read when image capture, and written when
> > > display. That means the clock, the address bus and data bus will be
> > > switched between the state of image capture/display and image process.
> > > Actually, I use two blocks: one for image capture/display and another
> > > for image process. And I use BUS MUX to switch address bus and data
> > > bus. Meanwhile, I use LPM MUX to switch the two clock of different
> > > frequency. Unfortunately, the instance does not meet timing. In Timing
> > > Analyzer Summary, it reports, Clock setup: 'pclk' has a slack of
> > > -4.152ns and Clock hold: 'pclk' has a slack of -4.216ns. What should I
> > > do to solve this problem?
>
> > > Best Regards,
> > > X.Y.
>
> > Assuming you are using the Classic Timing Analyzer, make sure you have
> > a CUT assignment between the two clock domains. In the QSF, you want
> > to see something like:
>
> > set_instance_assignment -from pclk -to <your pll clock name> -
> > name CUT ON
> > set_intance_assignment -from <your pll clock name> -to pclk -name
> > CUT ON
>
> > You can make these assignments using the Assignment Editor.
>
> > BTW, clock muxing is something the new TimeQuest Timing Analyzer does
> > very well. Here is an example of how to describe this in an SDC for
> > TimeQuest:
>
> >http://www.altera.com/support/examples/timequest/exm-tq-clock-mux.html
>
> > Hope this helps.
>
> > -David Karchmer
> > Altera- Hide quoted text -
>
> > - Show quoted text -
>
> Thanks for your reply! I use Classic Timing Analyzer. I want to try
> the CUT assignment. Unfortunately, I meet new problem. I right-click
> on the pclk pin and select locate in assignment editor. Then I select
> CUT Timing Path in the "assignment name" category and select the pll
> clock name in the "from" category. After that, I click save icon.
> Curiously, what I just assigned disappears. I open the QSF file, there
> is no my CUT assignment. How can I save my constraint setting?
>
> Best Regards.
> X.Y.- Hide quoted text -
>
> - Show quoted text -
X.Y.,
Quartus caches all the QSF information in memory, so even when you
click on save, you are just saving the Assignment Editor changes into
the in-memory QSF database. Quartus will automatically write out the
newest QSF when you either close the project (or revision), or start a
back-end process ("Compile" "Start Fitter", "Start Classic Timing
Analyzer", etc).
-David Karchmer
Altera
Article: 122821
Hi Mark,
markmcmahon@hotmail.com wrote:
> I've hit a brick wall with this. I just can't figure out what I'm
> doing wrong, or not doing right!
>
> microblaze_enable_interrupts();
> /* Register the UART interrupt handler in the vector table */
> XIntc_RegisterHandler(XPAR_OPB_INTC_0_BASEADDR,XPAR_OPB_INTC_0_PUSH_BUTTONS_1BIT_IP2INTC_IRPT_INTR,
> (XInterruptHandler)pb_int_handler,(void
> *)XPAR_PUSH_BUTTONS_1BIT_BASEADDR);
> /* Start the interrupt controller */
> XIntc_mMasterEnable(XPAR_OPB_INTC_0_BASEADDR);
> /* Enable PB interrupt requests in the interrupt controller */
> XIntc_mEnableIntr(XPAR_OPB_INTC_0_BASEADDR,XPAR_PUSH_BUTTONS_1BIT_IP2INTC_IRPT_MASK);
> /* Enable PB interrupts */
> XGpio_InterruptGlobalEnable(XPAR_PUSH_BUTTONS_1BIT_BASEADDR);
> XGpio_InterruptEnable(XPAR_PUSH_BUTTONS_1BIT_BASEADDR,
> XPAR_PUSH_BUTTONS_1BIT_IP2INTC_IRPT_MASK);
>
> /* Wait for interrupts */
> while (1){
> if (num_interrupts >= 1){
> xil_printf("-- Number of interrupts received : %x \n\r",
> num_interrupts);
> }
> When debugging I can see that the IE bit in the MSR gets set. The
> code hangs on
> XGpio_InterruptGlobalEnable(XPAR_PUSH_BUTTONS_1BIT_BASEADDR);
>
> The function in question from xgpio_intr.c:
>
> void XGpio_InterruptGlobalEnable(XGpio *InstancePtr)
> {
> XASSERT_VOID(InstancePtr != XNULL);
> XASSERT_VOID(InstancePtr->IsReady == XCOMPONENT_IS_READY);
> XASSERT_VOID(InstancePtr->InterruptPresent == XTRUE);
>
>
> XIIF_V123B_GINTR_ENABLE(InstancePtr->BaseAddress +
> XGPIO_IPIF_OFFSET);
> }
You are confusing the InstancePtr concept of the EDK driver model, with
the hardware BASEADDR (which is just the physical address of the
peripheral's hardware register set).
Check the various tutorials on using the EDK standalone driver model -
there are plenty of examples out there.
Here's one to get started with:
http://warp.rice.edu/trac/browser/Documentation/ReferenceDesigns/InterruptRef_xps_8_2/src/interruptTester.c
Regards,
John
Article: 122822Hi, PFC wrote: > >> I can only transmit through the board data at a maximum rate of 1Mbps. >> Anything more than that is lost. > > > You mean "to the board", not "through", yes ? > >> eg. When i transmit at 1.4Mbps, 400Kbps of data is lost, etc. >> And when I try to transmit at data rates over 3Mbps, I get on >> Hyperterminal the error messege that the Rx Fifo is full. > > > Well, I have never used Virtex4, but I have used a FPGA board > (Suzaku) with LAN91c111 MAC chip. > This, running Microblaze/ucLinux, achieved an ethernet bandwidth > of... 2 Mbps. Yes, that's a bit more than 200 kilobytes per second, ie. > ridiculous. Be fair - a major problem in Suzaku's configuration is the lack of DMA on the ethernet MAC. A simple fix would be to add an opb_dma controller to the system, and reconfigure the ethernet driver to use it. With the Xilinx EMAC core, full DMA, data realignment engine and checksum offload we see sustained 50Mbps throughput on MicroBlaze Linux systems at 100MHz. You are right that there is OS overhead, however the Linux kernel does as little packet copy as possible - once off the MAC to main memory (unavoidable), then once from kernel to user space. If you use sendfile() then it's zero copy. No operating system will get high performance on a badly bottlenecked hardware architecture! Regards, JohnArticle: 122823
>Have you actually contacted Xilinx? They have version back to the very >early days of FPGAs. > > Thanks for the response. Yes we did contact Xilinx and they do not have earlier versions. In any case have retrogressed to using 6.3 now and are hoping that it all works out. EchoArticle: 122824
Hey Guys, Did any of you get an email like this last weekend(see below)? What a crock! Like a mug, I signed in tonight with my regular Xilinx login, to check it out. Not exactly popular yet... I'm uncomfortable with an FPGA forum controlled by one of the de facto duopoly. (Sorry 'L' :-| ) I'd prefer they spent their effort on the public forum we already have. Anyway, if you post here on CAF and didn't get an email, clearly you're not a 'significant' contributor. I wonder what one has to do to be significant? Cheers, Syms. Symon, Thank you for your support and use of Xilinx products. We have recognized you as a significant contributor in regards to Xilinx products on comp.arch.fpga and would like to invite you to join our new Xilinx User Community. It will be opening to the public on August 13, 2007. Please see the information below on how to join. Sincerely, [Redacted] Customer Applications Manager
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