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
That is correct. I am debugging in hardware and there's an embedded processor along with a SpartanII FPGA. The reason I didn't want to resort to simulation is because I am modifying an existing design and the surrounding system is pretty complex, while the modification is not. Writing a testbench for the system would have been a tedious task. On Feb 25, 3:28 pm, Frank Buss <f...@frank-buss.de> wrote: <snip> > The bug was, that I didn't latched the (asynchronous) input signals. Frank, thanks for the idea. While I don't consider myself an experienced designer, I've been bitten by this before, yet I seem to have forgotten synchronizing and I think that is a big part of the problem. I'll try that first thing tomorrow! There's only one clock in the system, but there are latches and that's how I forgot. Dave, thanks for the idea. I'll try that too. For now I have resorted to the combinational process I've written earlier. Kevin, the clock for this design is pretty wide, so it's most likely a synchronization problem as you and Frank suggested. Thanks. /MHSArticle: 138526
mhelshou@hotmail.com wrote: > For debugging purposes. My FSM gets stuck somewhere and I wanted to be > able to read the current state as a register. I do something like this inside a process: out <= "000"; if state=INIT then out(0) <='1'; endif; if state=CLK_LOW then out(1) <='1'; endif; if state=CLK_HIGH then out(2) <='1'; endif; Then you can easily see illegal 2-hot or 0-hot states. I don't think you always can using a case statement or 'pos operator. -JeffArticle: 138527
HI All, I m looking for information regarding MCS and SVF file details. Exactly I need to know about how MCS file is interpreted when it is loaded into the PROM or else. I also eager to know about the SVF file instruction is interpreted by the impact tool. Is there any document for both? If then please refer me. I gone through the some of the Xapp Documents (058, 79 etc) for details but I dint get enough. Thanks in Advance, AppuArticle: 138528
On Feb 25, 5:38=A0pm, doug <x...@xx.com> wrote: > My Name wrote: > > In the general case, I and Q aren't normalized and cover a certain > > amplitude range. Some kind of normalization, e. g. dividing by I^2+Q^2, > > is required, if the decoder output has to be correctly scaled. Cause th= e > > carrier magnitude can be expected to vary only slowly, other means as a= n > > AGC can be used as well. This is the case with usual FM receivers.Has > > anyone =A0an idea about implementation of an AGC for fm demodulator? > > You do not need it. You are measuring angles not amplitude. In fact, in a typical analog FM receiver, amplitude noise can mess up reception of the signal so they clip the amplitude to remove the noise. RickArticle: 138529
Hello, I am working on a project where I have a chip that produces serial data. This data is to be sent to the PC via the USB, through an FPGA. I was wondering if the UFO-400 (Open FPGA project) board is the ideal choice as a prototype board. I wanted to look through examples from various vendors but only the open source project has code available (duh!) My considerations are the following things: 1. FPGA programming (all boards use standard Xilinx/Altera FPGAs. so this is not a problem) 2. Software interface on the PC - to not only program the FPGA but also to talk to the FPGA after programming. (I presume the vendors will provide this, I am concerned about the availability of the source code in case I want to modify this to suit my custom board) 3. USB controller firmware (Again, will I need to edit the firmware? If yes, would the open source project be the ideal choice?) any help is appreciated. Thanks! SrikanthArticle: 138530
rickman wrote: > In your case that may be useful. My point is that in the general case > this is not something that would be widely useful since PCIe ports are > a very "expensive" way to configure a part when all you really need is > four GPIO pins on the host. PCIe ports might be the least expensive way to configure the chips in near future. PCIe switches are very cheap nowadays and the high end embedded processors are going to the PCIe way. There are still GPIO pins/local-bus but they might be multiplexed with other functions. PCIe is a neat way of reducing pins in the packages. Also in many applications you need fast CPU access to the FPGA and for that PCIe is also a good protocol. Why put extra gpio pins if PCIe is already connected. Also loading time is one parameter, on big chips the configuration data is 10+Mbytes, the bus has to be quite fast. >> I was actually thinking of applications without the chance of using GPIO >> lines, e.g. on a PCIe plugin card. > > I don't know PCIe much, but I have worked with PCI before and I don't > think it is practical to use an FPGA to provide the PCI interface. > This issue may have been resolved at some point, but I want to say > that an FPGA does not boot fast enough to respond to the initial > enumeration comms on the bus. Has this issue been addressed so that > an FPGA can boot from an on board PROM and provide a PCIe interface? If we are talking about embedded applications then it would be easy to first load the FPGAs trough the PCIe and then do the enumeration or use PCI hotplug functionality. The newest FPGAs have PCIe hardcores so they could respond immediatly to the bus, and the loading could be done via extended configuration registers or some initial memory mapped area. For PCIe extension cards that are in standard PCs and needed during boot process I don't see easy ways to avoid some flash/prom solutions on the card. It would be nice to have standard way of uploading firmware images during bootup, maybe pcisig has something coming for this. I have not seen anything in the pci standards I have read. > I think the idea is that the image required to boot the FPGA enough to > make it bootable over the PCIe interface would be pretty stable. So > the concerns of needing to fix that would be a bit overblown. In My take on this is that usually all the places that can not be upgraded have some annoying bug, and field recalls are expensive way of fixing some small bug. I have seen that even PLD update logic is wired to CPUs to enable PLD updates in the field. > fact, it is likely that you could design the interface to the boot > Flash so that it can be programmed over the PCIe bus. Then, as long > as the reprogramming did not go bust in the middle, you could update > the Flash just like you load the rest of the image. This is one way of doing this. It's also quite easy to build fail safes to drop into previous image if the update does not succeed. But this still needs extra flash, software logic, extra logic etc. This could be avoided in some situations. --KimArticle: 138531
>I am working on a project where I have a chip that produces serial >data. This data is to be sent to the PC via the USB, through an FPGA. >I was wondering if the UFO-400 (Open FPGA project) board is the ideal >choice as a prototype board. What do you mean by "serial data"? Do you mean typical ASCII over RS-232? If so, why do you need a FPGA? So I assume you mean some other form of serial encoding. My straw man would be to use a USB-RS-232 conversion dongle with some sort of FPGA/CPLD to do the conversion from your version of serial to RS-232 serial (8N1 or whatever). -- These are my opinions, not necessarily my employer's. I hate spam.Article: 138532
On Feb 26, 3:11=A0pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > >I am working on a project where I have a chip that produces serial > >data. This data is to be sent to the PC via the USB, through an FPGA. > >I was wondering if the UFO-400 (Open FPGA project) board is the ideal > >choice as a prototype board. > > What do you mean by "serial data"? > > Do you mean typical ASCII over RS-232? =A0If so, why do you > need a FPGA? > > So I assume you mean some other form of serial encoding. > > My straw man would be to use a USB-RS-232 conversion dongle > with some sort of FPGA/CPLD to do the conversion from your > version of serial to RS-232 serial (8N1 or whatever). > > -- > These are my opinions, not necessarily my employer's. =A0I hate spam. i did similarity project before, we choiced cy7c68013 from cypress. it's a ease usb chip, and can work in slave fifo mode. data rate is up to 38MB.Article: 138533
rickman;468985 Wrote: > On Feb 25, 5:38*pm, doug <x...@xx.com> wrote: > > My Name wrote: > > > In the general case, I and Q aren't normalized and cover a certain > > > amplitude range. Some kind of normalization, e. g. dividing by > I^2+Q^2, > > > is required, if the decoder output has to be correctly scaled. > Cause the > > > carrier magnitude can be expected to vary only slowly, other means > as an > > > AGC can be used as well. This is the case with usual FM > receivers.Has > > > anyone *an idea about implementation of an AGC for fm demodulator? > > > > You do not need it. You are measuring angles not amplitude. > > In fact, in a typical analog FM receiver, amplitude noise can mess up > reception of the signal so they clip the amplitude to remove the > noise. > > > > So you say that the only thing i have to compute to demodulate the > signal is just Q*dI/dt - I*dQ/dt?In a similar conversation.....'Division > Approximation In Fm Demodulator - Page 2 - Altera Forums' > (http://www.alteraforum.com/forum/showthread.php?t=4696&page=2) for some > people this is not right!!! -- xristos ------------------------------------------------------------------------ xristos's Profile: http://www.fpgacentral.com/group/member.php?userid=15 View this thread: http://www.fpgacentral.com/group/showthread.php?t=88112Article: 138534
srikanthv2 <srikanthv2@gmail.com> wrote: > Hello, > I am working on a project where I have a chip that produces serial > data. This data is to be sent to the PC via the USB, through an FPGA. > I was wondering if the UFO-400 (Open FPGA project) board is the ideal > choice as a prototype board. > I wanted to look through examples from various vendors but only the > open source project has code available (duh!) > My considerations are the following things: > 1. FPGA programming (all boards use standard Xilinx/Altera FPGAs. so > this is not a problem) > 2. Software interface on the PC - to not only program the FPGA but > also to talk to the FPGA after programming. (I presume the vendors > will provide this, I am concerned about the availability of the source > code in case I want to modify this to suit my custom board) > 3. USB controller firmware (Again, will I need to edit the firmware? > If yes, would the open source project be the ideal choice?) > any help is appreciated. Thanks! Look at the FTDI chips, FT232/245/2322/D and 2322H -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 138535
On 23 Feb., 20:36, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Jaime Andr=E9s Aranguren Cardona wrote: > > > I am building a system wich employs the DDR controller generated by > > MIG 2.0 for a DDR memory + Spartan3E. So far the simulations work > > fine, and according to the waveforms on UG086. > > I am also interested in using DDR with the Spartan 3E (such > as on the Digilent Spartan 3E board.) =A0Most of my problems > should be relatively simple. =A0I don't need the full speed, or > even bursts of more than one. =A0I haven't looked at UG086 yet. > > -- glen Hi Glen, all guys. The MIG code seems to work, in simulation at least. Well, I know it does come with a simulation testbench and so on, but since later on I will move to a different FPGA (S3A) with the same DDR chip, I decided to start with the S3E kit for tthe HW test but I am fine tuning it myself, which means that I create both a "generic" DDR project, and a S3E kit project in MIG, and I base all of my tests on the "generic" code, and later hand customize it for this kit (clock input, location and timing constraints from kit's UCF, etc...) I am testing against the model provided by micron.com, and it seems to read / write in simulation. My problem now is to correctly generate the col/row/bank addresses. BTW: could you provide some enlightment about how to correctly generate them? For my initial test I just want to continuously and sequentially (from address 0 to 1023, in a linear fashion) write a sequence of numbers (0 to 1023), then read back in the same order and check if I read what I intended to write. My problem now is how to generate the sequential addresses (linea fashion) vs. row/col/bank which is needed for the MIG DDR controller. Any hints will be appreciated. JaaCArticle: 138536
I'm not going to agree on the UFO-400 for obvious reasons. But have a look at http://www.enterpoint.co.uk/cpld_boards/polmaddie1.html if you just want an interfacing board. The related Polmaddie3 will be a very useful board and will be with us soon as with be numbers 2,4 and 5. There are other boards with the FT232 chip fitted coming and one of those will annouce this week and amother in 4-8 weeks time that will be a very good competitor to the UFO-400. All of the FT232 based offerings give a simple interface to get up and going. Most terminal emulators to start with or more advanced direct serial (usb) port driving if you want that way of doing things. John Adair Enterpoint Ltd. On 26 Feb, 06:03, srikanthv2 <srikant...@gmail.com> wrote: > Hello, > I am working on a project where I have a chip that produces serial > data. This data is to be sent to the PC via the USB, through an FPGA. > I was wondering if the UFO-400 (Open FPGA project) board is the ideal > choice as a prototype board. > > I wanted to look through examples from various vendors but only the > open source project has code available (duh!) > > My considerations are the following things: > > 1. FPGA programming (all boards use standard Xilinx/Altera FPGAs. so > this is not a problem) > 2. Software interface on the PC - to not only program the FPGA but > also to talk to the FPGA after programming. (I presume the vendors > will provide this, I am concerned about the availability of the source > code in case I want to =A0modify this to suit my custom board) > > 3. USB controller firmware (Again, will I need to edit the firmware? > If yes, would the open source project be the ideal choice?) > > any help is appreciated. Thanks! > > SrikanthArticle: 138537
On Feb 26, 6:30=A0am, Jaime Andr=E9s Aranguren Cardona <jaime.arangu...@gmail.com> wrote: > On 23 Feb., 20:36, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > > Jaime Andr=E9s Aranguren Cardona wrote: > > > > I am building a system wich employs the DDR controller generated by > > > MIG 2.0 for a DDR memory + Spartan3E. So far the simulations work > > > fine, and according to the waveforms on UG086. > > > I am also interested in using DDR with the Spartan 3E (such > > as on the Digilent Spartan 3E board.) =A0Most of my problems > > should be relatively simple. =A0I don't need the full speed, or > > even bursts of more than one. =A0I haven't looked at UG086 yet. > > > -- glen > > Hi Glen, all guys. > > The MIG code seems to work, in simulation at least. Well, I know it > does come with a simulation testbench and so on, but since later on I > will move to a different FPGA (S3A) with the same DDR chip, I decided > to start with the S3E kit for tthe HW test but I am fine tuning it > myself, which means that I create both a "generic" DDR project, and a > S3E kit project in MIG, and I base all of my tests on the "generic" > code, and later hand customize it for this kit (clock input, location > and timing constraints from kit's UCF, etc...) > > I am testing against the model provided by micron.com, and it seems to > read / write in simulation. My problem now is to correctly generate > the col/row/bank addresses. BTW: could you provide some enlightment > about how to correctly generate them? For my initial test I just want > to continuously and sequentially (from address 0 to 1023, in a linear > fashion) write a sequence of numbers (0 to 1023), then read back in > the same order and check if I read what I intended to write. My > problem now is how to generate the sequential addresses (linea > fashion) vs. row/col/bank which is needed for the MIG DDR controller. > > Any hints will be appreciated. > > JaaC For Spartan 3 MIG, which is primitive compared to the Virtex 5 MIG, the order of row vs. bank addressing is not important. This is due to the fact that the MIG code only leaves one row of one bank active at any time. The column address should be your low order address bits for linear addressing. This will prevent unnecessary row precharge / activate sequences when performing linear access to memory. Also note that the least significant bits of the column address are incremented inside the memory chip during a burst operation. There is no carry out to the upper address bits, so when starting a burst you should normally begin at a burst boundary to avoid rapping back to previous addresses. Be careful when using the MIG top level interface with "linear" address. It may be using the least significant bits for the bank address (depends on which interface type DDR, DDR2, etc.). Regards, GaborArticle: 138538
Hi all, it is not an answer for Mikel's question, but I have an other question which is related to this topic. Does anybody know how the parity bits are calculated exactly? They are stored in the bits 640 to 651 (21. Dataword) of each Configuration Frame of the Bitstream. I know it is a Hamming Code but what happens with the 21. Dataword? Is it used for the Calculation of this parity Bits? I hope someone can help me. Thanks, Matthias R.Article: 138539
On Feb 26, 10:18=A0am, Allan Herriman <allanherri...@hotmail.com> wrote: > rickman <gnu...@gmail.com> wrote innews:9e5e3729-4da1-41b4-9ec2-9c8f5dfe2= 4d6@r36g2000vbp.googlegroups.com: > > > > > On Feb 25, 4:49 am, Allan Herriman <allanherri...@hotmail.com> wrote: > >> rickman <gnu...@gmail.com> wrote > >> innews:3774b465-11f4-4daa-aee7-d44f72fce9a6@n20g2000vba.googlegroups.c > >> om: > > >> > On Feb 24, 8:27 am, Allan Herriman <allanherri...@hotmail.com> > >> > wrote: > >> >> "Krzysztof Kepa" <nospam_blond...@poczta.fm> wrote > >> >> innews:go0pr0$6jj$1@ai > >> > oe.org: > > >> >> > "Allan Herriman" <allanherri...@hotmail.com> wrote in message > >> >> >news:Xns9BBCD0C44FABBallanherrimanhotmail@216.151.153.43... > >> >> >> Hi, > > >> >> >> I guess my questions are: > > >> >> >> 2. =A0Will future generations FPGAs be able to be programmed via > >> >> >> PCIe? If so, when? > > >> >> > Now? ;) Just need to use some external =A0components to tie it > >> >> > together...or use partial reconfiguration (PR) flow. > > >> >> I meant "gluelessly". =A0With PR, one must get the original > >> >> configuration into the FPGA somehow, and (as I understand it) that > >> >> cannot be done with PCIe. > > >> >> Thanks for your comments. > > >> >> Allan > > >> > I haven't looked at processors like the Atom in a while, but I seem > >> > to recall that you get some number of general purpose I/O pins on > >> > most any processor. =A0You only need four pins to completely control > >> > an FPGA configuration; PRGM, CCLK, DONE, INIT. =A0They can be bit > >> > banged in software. =A0The FPGA interface is not used very much when > >> > considered in the grand scheme of things. =A0So I expect you will > >> > never see direct support for it on processors. > > >> > I also doubt that you will see dedicated support for PCIe in FPGAs. > >> > This is a bit lofty for a configuration interface. =A0PCIe is point > >> > to point (right?) and taking one of the two PCIe interfaces on an > >> > Atom for booting the FPGA would be a bit of overkill. =A0There are > >> > few applications where a processor like the Atom is used and you > >> > can't wait the few milliseconds for the FPGA to boot serially. > > >> That PCIe isn't wasted; it is needed for FPGA <-> cpu comms after > >> configuration. > > > In your case that may be useful. =A0My point is that in the general cas= e > > this is not something that would be widely useful since PCIe ports are > > a very "expensive" way to configure a part when all you really need is > > four GPIO pins on the host. > > >> I was actually thinking of applications without the chance of using > >> GPIO lines, e.g. on a PCIe plugin card. > > > I don't know PCIe much, but I have worked with PCI before and I don't > > think it is practical to use an FPGA to provide the PCI interface. > > This issue may have been resolved at some point, but I want to say > > that an FPGA does not boot fast enough to respond to the initial > > enumeration comms on the bus. =A0Has this issue been addressed so that > > an FPGA can boot from an on board PROM and provide a PCIe interface? > > >> It still seems that the PCIe to local bus bridge is the best solution > >> for my hypothetical problem. =A0The other suggestions involved Flash > >> memories (with an implied extra step during manufacturing to program > >> the dang things, not to mention the extra complexity involved with > >> in-the-field upgrades of that image) or a non-trivial amount of glue > >> logic. > > > I think the idea is that the image required to boot the FPGA enough to > > make it bootable over the PCIe interface would be pretty stable. =A0So > > the concerns of needing to fix that would be a bit overblown. =A0In > > fact, it is likely that you could design the interface to the boot > > Flash so that it can be programmed over the PCIe bus. =A0Then, as long > > as the reprogramming did not go bust in the middle, you could update > > the Flash just like you load the rest of the image. > > > Of course, the local bus interface still requires some extra logic to > > boot the FPGA, no? =A0Or does the bridge chip provide signals that can > > be used directly? > > They usually have a few GPIO lines as well as a parallel data bus. =A0Thi= s > allows some sort of slave parallel mode to be used without glue logic. > > Just in case you are interested, here are some typical parts: > > 1 Lane:http://www.plxtech.com/products/expresslane/pex8311.asp > > 4 Lanes with dedicated FPGA loading support:http://www.gennum.com/video/p= roducts/gn4124 > > Here's the article that inspired this thread:http://www.pldesignline.com/= howto/210300269 Here's another one that looks quite nice: PCIe x4, 2xDMA, DDR SDRAM controller (presumably for DMA buffers), 2x I2C controllers, SPI, 8x GPIO, FPGA configuration logic, serial port, 64 bit / 133MHz local bus. http://www.avaldata.com/products/y2_technology/pci-express_bridge/aaeb04.ht= ml (It's in Japanese.) I found a product brief in English here: http://www.daitron.com/aval_data/pdf/AVAL%20DATA%20Brief%20Sheet%20Jul23%20= 08.pdf Regards, AllanArticle: 138540
Allan Herriman <allanherriman@hotmail.com> writes: > They're not so big an expensive compared with the other solutions I've > been considering. The silicon costs a few dollars more, but I can > eliminate the manufacturing step for programming a Flash. You mean the time it takes to program a flash during production? I haven't read the entire thread, but I've done something similar before. Use a configuration flash with a serial interface (or use more pins on your FPGA). Program a failsafe version in bank-0 of the flash during production. You can use the JTAG signals on the PCIe connector in conjunction with a test-jig present signal to do this. I've used the SVF file as a base to generate these vectors. Make a register in the address space of your PCIe FPGA design available to software. Connect this register to JTAG (or some parallel bus if your prefer to use more pins). You can now write into bank-1 of the flash from the host CPU over PCIe. Set the bank-1 select bit. Reboot or let your host software run the enumeration over again. Make some disaster method to switch back to bank-0. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 138541
On Feb 26, 3:14=A0am, 'use_real_email' wrote: > rickman;468985 Wrote: > > > > > > > On Feb 25, 5:38*pm, doug <x...@xx.com> wrote: > > > My Name wrote: > > > > In the general case, I and Q aren't normalized and cover a certain > > > > amplitude range. Some kind of normalization, e. g. dividing by > > I^2+Q^2, > > > > is required, if the decoder output has to be correctly scaled. > > Cause the > > > > carrier magnitude can be expected to vary only slowly, other means > > as an > > > > AGC can be used as well. This is the case with usual FM > > receivers.Has > > > > anyone *an idea about implementation of an AGC for fm demodulator? > > > > You do not need it. You are measuring angles not amplitude. > > > In fact, in a typical analog FM receiver, amplitude noise can mess up > > reception of the signal so they clip the amplitude to remove the > > noise. > > > So you say that the only thing i have to compute to demodulate the > > signal is just Q*dI/dt - I*dQ/dt?In a similar conversation.....'Divisio= n > > Approximation In Fm Demodulator - Page 2 - Altera Forums' > > (http://www.alteraforum.com/forum/showthread.php?t=3D4696&page=3D2) for= some > > people this is not right!!! > > -- > xristos > ------------------------------------------------------------------------ > xristos's Profile:http://www.fpgacentral.com/group/member.php?userid=3D15 > View this thread:http://www.fpgacentral.com/group/showthread.php?t=3D8811= 2- Hide quoted text - > > - Show quoted text - Try the CORDIC in hardware to do atan(Q/I) - 10 stages or so or use xilinx coregen to make one, it will provide a great response rather than doing the a derivative by subtracting. Example C/matlab code is all over the internet for this, though either method should work. If you are receiving over the air - save some output to a file. You can then do a fft on the output of the CORDIC where you should get the MPX signal. Then look for a tone at 19K Hz (if a stereo channel) to see if you are on the right track.Article: 138542
On Feb 26, 3:24=A0am, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > >I guess the bigger question here is how to correctly > >interface a little endian peripheral to a big-endian > >SoC ? > > It's a hard problem. =A0It's been around for ages. > > >Byte swapping everything would mean that the user manual > >for the pripoheral would have to be rewritten as well ... > > You may want byte swapping in the hardware. =A0It depends > on what you are talking to. =A0If it's something like a disk > or ethernet, where you often transfer text, you are probably > better off treating it as a byte stream which means you will > have to byte-swap (in software) to use things like 4 byte > integers. > > Note that if you byte-swap the bus pins, that will > byte swap addresses on a shared bus. =A0So you may have > to swap addresses in the driver so they will come out > right when the hardware swaps them again. > > You can probably write a user manual that covers both > cases. =A0The trick is to write it using words and word > addresses/offsets, then describe each word with > pictures and bit offsets or terms like "high byte" > rather than byte addresses. =A0"Word" in that sentence > means whatever the natural width of the bus is. > > Or you can just describe it for the normal/natural case > and let the poor guy who is using it on the wrong-endian > system sort things out. =A0He should be familiar with the > problem and know how to read wrong-endian data sheets. > > -- > These are my opinions, not necessarily my employer's. =A0I hate spam. Thanks for all the feedback guys ! Doing it software is not really feasible. I am working on a new demo for our SATA II Host Controller for Virtex 5, and was trying to implement the dosfs code that was pointed out by Antti. Thats when I discovered that all the bytes where reversed. It did not occur to me while I was writing the sector read and write routines, as all data transfers where done by DMA (on word boundaries). So it really has to be byte swapped in hw to make it work correctly. Cheers, rudiArticle: 138543
On Feb 25, 2:14=A0pm, gabor <ga...@alacron.com> wrote: > On Feb 25, 9:51=A0am, colin <colin_toog...@yahoo.com> wrote: > > > Hello > > > I have a new virtex 5 design with a lot of IO going at the same speed. > > I've been told to put all this IO on the same column. Also I can then > > use the DCI bank cascading. > > > Does anyone know the logic behind the bank numbering? I can't find any > > data on which banks are in which column. > > > Colin > > You really need to dig for this information. =A0I was told to use > "ADEPT" to get a picture of the columns. =A0There is a long > thread on the Xilinx forums about this. > > http://forums.xilinx.com/xlnx/board/message?board.id=3DVirtex&thread.id..= . > > Regards, > Gabor The ISE PinAhead tool gives a color-coded column breakdown of all banks (User Constraints -> Floorplan Area)Article: 138544
On Feb 26, 7:55=A0pm, luudee <rudolf.usselm...@gmail.com> wrote: > On Feb 26, 3:24=A0am, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal > > > > Murray) wrote: > > >I guess the bigger question here is how to correctly > > >interface a little endian peripheral to a big-endian > > >SoC ? > > > It's a hard problem. =A0It's been around for ages. > > > >Byte swapping everything would mean that the user manual > > >for the pripoheral would have to be rewritten as well ... > > > You may want byte swapping in the hardware. =A0It depends > > on what you are talking to. =A0If it's something like a disk > > or ethernet, where you often transfer text, you are probably > > better off treating it as a byte stream which means you will > > have to byte-swap (in software) to use things like 4 byte > > integers. > > > Note that if you byte-swap the bus pins, that will > > byte swap addresses on a shared bus. =A0So you may have > > to swap addresses in the driver so they will come out > > right when the hardware swaps them again. > > > You can probably write a user manual that covers both > > cases. =A0The trick is to write it using words and word > > addresses/offsets, then describe each word with > > pictures and bit offsets or terms like "high byte" > > rather than byte addresses. =A0"Word" in that sentence > > means whatever the natural width of the bus is. > > > Or you can just describe it for the normal/natural case > > and let the poor guy who is using it on the wrong-endian > > system sort things out. =A0He should be familiar with the > > problem and know how to read wrong-endian data sheets. > > > -- > > These are my opinions, not necessarily my employer's. =A0I hate spam. > > Thanks for all the feedback guys ! > > Doing it software is not really feasible. I am working on a > new demo for our SATA II Host Controller for Virtex 5, and > was trying to implement the dosfs code that was pointed out > by Antti. Thats when I discovered that all the bytes where > reversed. It did not occur to me while I was writing the > sector read and write routines, as all data transfers where > done by DMA (on word boundaries). > > So it really has to be byte swapped in hw to make it work > correctly. > > Cheers, > rudi if you did use 32 bit DMA transfer to DOS file buffer then yes it would appear as all wrong but, well microblaze is WRONG endian it just makes lots of trouble least significant byte of a word is at byte offset +3 :( but this is what normally is read as first byte from byte wide streaming interface, also from disk file system. on MB system your DMA should but te FIRST byte as bits 31.24 then it should be ok you probably need ad some parameter to swap bytes into normal order or not depening the endianess, doing it in software is not feasible the same problem happens all around, USB, ethernet packets need adjust the byte order many times to get it right. i think there was lots of trouble with some early microblaze linux usb drivers, when those did work then the usb based ethernet adapters did not work, wanted own endian swap.. AnttiArticle: 138545
acrawfor29@gmail.com wrote: > On Feb 26, 3:14 am, 'use_real_email' wrote: > >>rickman;468985 Wrote: >> >> >> >> >> >> >>>On Feb 25, 5:38*pm, doug <x...@xx.com> wrote: >>> >>>>My Name wrote: >>>> >>>>>In the general case, I and Q aren't normalized and cover a certain >>>>>amplitude range. Some kind of normalization, e. g. dividing by >>> >>>I^2+Q^2, >>> >>>>>is required, if the decoder output has to be correctly scaled. >>> >>>Cause the >>> >>>>>carrier magnitude can be expected to vary only slowly, other means >>> >>>as an >>> >>>>>AGC can be used as well. This is the case with usual FM >>> >>>receivers.Has >>> >>>>>anyone *an idea about implementation of an AGC for fm demodulator? >> >>>>You do not need it. You are measuring angles not amplitude. >> >>>In fact, in a typical analog FM receiver, amplitude noise can mess up >>>reception of the signal so they clip the amplitude to remove the >>>noise. >> >>>So you say that the only thing i have to compute to demodulate the >>>signal is just Q*dI/dt - I*dQ/dt?In a similar conversation.....'Division >>>Approximation In Fm Demodulator - Page 2 - Altera Forums' >>>(http://www.alteraforum.com/forum/showthread.php?t=4696&page=2) for some >>>people this is not right!!! >> >>-- >>xristos >>------------------------------------------------------------------------ >>xristos's Profile:http://www.fpgacentral.com/group/member.php?userid=15 >>View this thread:http://www.fpgacentral.com/group/showthread.php?t=88112- Hide quoted text - >> >>- Show quoted text - > > > Try the CORDIC in hardware to do atan(Q/I) - 10 stages or so or use > xilinx coregen to make one, it will provide a great response rather > than doing the a derivative by subtracting. Example C/matlab code is > all over the internet for this, though either method should work. > > If you are receiving over the air - save some output to a file. You > can then do a fft on the output of the CORDIC where you should get the > MPX signal. Then look for a tone at 19K Hz (if a stereo channel) to > see if you are on the right track. There is also a verilog version of the cordic routine available. It is plenty fast and is easy to implement. For those who are not familiar with the cordic, it rotates the vector to zero and sees how much angle it needs to do that. You get the angle from that. >Article: 138546
On Feb 25, 11:15=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > On Feb 23, 4:49=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > On Feb 23, 12:42=A0pm, Dave Pollum <vze24...@verizon.net> wrote: > > > > On Feb 23, 3:38=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > Hi, > > > > It is intersting to find that $24.50 is for an Altera ByteBlast > > > > programmer mentioned in a topics in FPGA group. > > > > > I need to buy a programmer suitable for Xilinx Virtex II XC2V1500 c= hip > > > > only. > > > > > Please give any tips where I can buy a cheap programmer. > > > > > Thank you. > > > > > Weng > > > > Digilent (digilentinc.com) has inexpensive programming cables. > > > -Dave Pollum > > > Hi Dave, > > Good information! I need cables too. But hopefully I may get a set of > > programmer plus its cables from one person or a company. > > > Weng- Hide quoted text - > > > - Show quoted text - > > Hi Dave, > I checked Digilent.com website and I am not sure which one works for > my system: Xilinx Virtext II XC2V 1000. > > JTAG Programming Cable $12.00 > low-cost JTAG configuration solution > for use with any JTAG-programmable device > connects directly to the parallel port of a PC, and to a standard 6- > pin JTAG programming header > can program devices that have a JTAG voltage of 1.8V or greater > > I found my board has a 14-pin connector, but above specs says it has a > 6-pin JTAG programming header. Is it fit? > > Is Xilinx iMPACT software still usable? > > Please give me a help to determine if which is fit. > > Thank you. > > Weng software still usable, go for jtag usb programming cable (37.95$), it will be faster it works with impact software for jtag the most important six connections are VCC, GND, TMS, TDI, TDO, TCK the 14 pin connector repeats some of the pins but effectively these six pins are required to program xilinx fpgas. You can make a manual adaptor with 6 Pin MTE Cable (also on the same page) which will break individual signal (TMS, TCK etc) into wires hope this helps makArticle: 138547
On Feb 26, 1:51 am, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > rickman wrote: > > In your case that may be useful. My point is that in the general case > > this is not something that would be widely useful since PCIe ports are > > a very "expensive" way to configure a part when all you really need is > > four GPIO pins on the host. > > PCIe ports might be the least expensive way to configure the chips in > near future. PCIe switches are very cheap nowadays and the high end > embedded processors are going to the PCIe way. There are still GPIO > pins/local-bus but they might be multiplexed with other functions. PCIe > is a neat way of reducing pins in the packages. Also in many > applications you need fast CPU access to the FPGA and for that PCIe is > also a good protocol. Why put extra gpio pins if PCIe is already > connected. Also loading time is one parameter, on big chips the > configuration data is 10+Mbytes, the bus has to be quite fast. When you refer to "high end" processors, you are talking about a literal handful of devices compared to the hundreds or thousands of types of CPUs that are used in embedded systems. If you are talking about adding a "switch" then you are adding an extra chip and you can just as easily add any sort of chip to facilitate booting the FPGA. My point is that you only need four pins for a serial boot at fairly high speed and this is still the cheapest way to go in 99% of the systems using a processor to boot the FPGA. The boot time is typically limited, not by the interface, but by the FPGA. > >> I was actually thinking of applications without the chance of using GPIO > >> lines, e.g. on a PCIe plugin card. > > > I don't know PCIe much, but I have worked with PCI before and I don't > > think it is practical to use an FPGA to provide the PCI interface. > > This issue may have been resolved at some point, but I want to say > > that an FPGA does not boot fast enough to respond to the initial > > enumeration comms on the bus. Has this issue been addressed so that > > an FPGA can boot from an on board PROM and provide a PCIe interface? > > If we are talking about embedded applications then it would be easy > to first load the FPGAs trough the PCIe and then do the enumeration or > use PCI hotplug functionality. The newest FPGAs have PCIe hardcores so > they could respond immediatly to the bus, and the loading could be done > via extended configuration registers or some initial memory mapped area. I'm not familar with PCIe, but I know in PCI apps you can't use the PCI interface to boot the FPGA. Are you talking about an embedded app where you can work "around" the PCIe spec and just talk to the FPGA without worrying about the spec'd protocol? In that case you have one of the few apps where your PCIe port is dedicated to the FPGA. Yes, in that case this works. But that is rare enough that the FPGA vendors aren't going to add that capability for those few apps. > For PCIe extension cards that are in standard PCs and needed during boot > process I don't see easy ways to avoid some flash/prom solutions on the > card. It would be nice to have standard way of uploading firmware images > during bootup, maybe pcisig has something coming for this. I have not > seen anything in the pci standards I have read. I seem to recall that there was support for a JTAG or some other serial interface on PCI, but it has been so long that I don't recall. > > I think the idea is that the image required to boot the FPGA enough to > > make it bootable over the PCIe interface would be pretty stable. So > > the concerns of needing to fix that would be a bit overblown. In > > My take on this is that usually all the places that can not be upgraded > have some annoying bug, and field recalls are expensive way of fixing > some small bug. I have seen that even PLD update logic is wired to > CPUs to enable PLD updates in the field. You are talking about systems that have no upgrade capability. I am talking about a minimum boot capability that is very unlikely to need an upgrade once it is tested and in the field. Heck, if engineers can't produce some level of accurate, working design then how do chips ever get made??? It is pretty hard to field upgrade an IC. ;^) > > fact, it is likely that you could design the interface to the boot > > Flash so that it can be programmed over the PCIe bus. Then, as long > > as the reprogramming did not go bust in the middle, you could update > > the Flash just like you load the rest of the image. > > This is one way of doing this. It's also quite easy to build fail safes > to drop into previous image if the update does not succeed. But this > still needs extra flash, software logic, extra logic etc. This could > be avoided in some situations. The logic is in the FPGA and is trivial in all but CPLDs perhaps. The "extra flash" is literally pennies in any design and is typically worth the small increment in cost. But sure, there is more than one way to skin a cat. RickArticle: 138548
>but, well microblaze is WRONG endian it just makes >lots of trouble It should be simple to make a RIGHT endian version of microblaze. It's probably just a few lines of text. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 138549
>"So far, it seems the best way is (despite the FPGA on-board >transceivers) to use a PCIe to local bus bridge chip from PLX or Gennum." > >They're not so big an expensive compared with the other solutions I've >been considering. The silicon costs a few dollars more, but I can >eliminate the manufacturing step for programming a Flash. I don't think you can elimintate that flash programming. The PLX chips need a tiny bit of external data to tell them their device ID. There may be some other parameters in there too. Without someting like that, the OS can't tell your board from my board that uses the same PLX chip. -- These are my opinions, not necessarily my employer's. I hate spam.
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