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
Hi, first I would like to suggest to get rid of this construction "always @(posedge iHCLKBUF or negedge nSYSRST)" as it is not really a synthesised construction, so your multiplexer will never operate properly, you can see it in PP&R simulations. Second, your code is not really a multiplexer, but a FF. So I would recommend to think more on architecture. Hope it will help. Regards, Alex > Hello Guys, > > I am working on some verfication of the SoC IP. To verify these IP we > are implementing it on FPGA. > I am facing an strange problem. > > One of the IP which i have implemented as Master and slave AHB > interface. Since the AMBA interface > i am having is a multiplexed bus i need to multiplex the master and > slave interface signal. So to do that > i am using grant signal of AHB to multiplex common signal (of master > and slave). But the problem is in > slave mode (grant signal is zero), external HBURST[2:0]=000 (seen > through logic analyzer), i have tapped > the internal HBURST to test point, i observed that the tapped internal > signal value is different from the external HBURST. > > Internally i am connecting the HBURST to slave HBURST port and to > multiplex HBURST i am using the below assign for master mode > > assign SGNTi = HGRANT[2]; > > always @(posedge iHCLKBUF or negedge nSYSRST) > begin : p_MasterEnable > if (nSYSRST == 1'b0) > AHBMasterEnable <= 1'b0; > else > if (HREADY == 1'b1) > AHBMasterEnable <= SGNTi; > end > assign HBURST = (AHBMasterEnable == 1'b1) ? iHBURSTOut : 3'bzzz; > > iHburstOut is signal which is driven by the Master interface of the IP. > > I am not able to understand how does the HBURST signal tapped (test > point) changed to something other then the external HBURST (HGRANT=0)? > > One more doubt: > Is there any problem in assign the incoming HBURST directly to test > point? > > waiting for ur reply, > Thanks and regards > williams > -- AlexArticle: 88651
yes i have tried it with impact open, and also with impact closed neither way seems to work thanks -- Geoffrey Wall Masters Student in Electrical/Computer Engineering Florida State University, FAMU/FSU College of Engineering wallge@eng.fsu.edu Cell Phone: 850.339.4157 ECE Machine Intelligence Lab http://www.eng.fsu.edu/mil MIL Office Phone: 850.410.6145 Center for Applied Vision and Imaging Science http://cavis.fsu.edu/ CAVIS Office Phone: 850.645.2257 "Duane Clark" <dclark@junkmail.com> wrote in message news:JUJOe.362$sV7.103@newssvr21.news.prodigy.com... > geoffrey wall wrote: >> I am trying to use chipscope to debug a simple design >> on the digilent spartan 3 starter board >> I insert a chipscope core using ISE 7.1 >> i synthesize my design and download it to the board >> via impact. >> now when I do analyze design using chipscope from within ISE >> chipscope starts, and I click the open cable icon in the upper left >> corner >> and the machine just sits for awhile, searching each LPT port >> (yes the parallel jtag cable is connected to the machine and the board) >> each of them time out i guess, and chipscope tells me: >> >> ERROR: Socket Open Failed. localhost/127.0.0.1:50001 >> localhost >> java.net.ConnectException: Connection refused: connect >> ERROR: Socket communication not open. >> >> any ideas? >> > > Did you first close impact? Only one can be open at a time; they > apparently compete for the port.Article: 88652
Well you might be pleasantly surprised by the new board. EAR, to use the acronym, affects some leading edge-ish semiconductors if you onward ship the devices or products made from them. Items that can be "dual use" especially can be affected, "Dual Use" refers to an item finding its way into military kit when it's origional function was purely commercial. It is conceivable that FPGA development boards could be used for something outside their intended use because they are user programmable. More of a problem that say a PCI card with a fixed function. The US also have embargoed countries that technically can't be shipped to. Failure to observe these regulations can bring fines and I believe imprisonment. Someone from the US may say that my understanding is incorrect and I don't claim to be any expert in these matters. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "c d saunter" <christopher.saunter@durham.ac.uk> wrote in message news:dehvgq$p56$1@heffalump.dur.ac.uk... > John, > I had a look at the Broaddown2 module, and one item I couldn't see was > a user Flash device - although the platform flash can be used for user > data it's sometimes convenient to have a physically seperate flash, and > these days you can get some large storage, physically tiny SPI devices. > > Also as an asside, I was interested to see your note on the US & UK export > regulations - can you expand any details on that? Top Secret pinout on the > edge connectors :-) or regulations on the FPGA? > > Regards, > Chris > > John Adair (removethisthenleavejea@replacewithcompanyname.co.uk) wrote: > : Representing a manufacturer of development boards I am going offer you > all > : the chance to have your say on what is goes into our new product > : Raggedstone1 and it's supporting modules. > > : What I can tell is that the board is very cheap and takes what we think > are > : some of the best attributes of the our existing Broaddown2 and MINI-CAN > : products. Like them it is also a Spartan-3 board (why another! - well > you > : just have to wait and see when we start revealing features in about 4 > weeks > : time). We have also included ideas based on existing customer feedback > on > : the Broaddown2 and MINI-CAN products. > > : We are now in the last week of layout and have found some small areas of > : board space that we might stick something on. So do your worst and > suggest > : (politely please) what we might give you in features. Even if your idea > is > : too big, or expensive, for Raggedstone1 itself then it may make our > add-on > : module list or even the next higher end Broaddown3/4 product launches. > > : John Adair > : Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development > : Board. > : http://www.enterpoint.co.uk > : > >Article: 88653
In article <1124872726.737546.229630@o13g2000cwo.googlegroups.com>, pho <philippe.hostiou@orange.fr> wrote: >Hello, >I would to use a simple/easy way to send, in multicast address, some >IP packets fprm a FPGA Xilinx VIRTEX4 to a Ethernet network. But I >don't want to use the PowerPC and its EMAC controller. I read that >the PHY interface can be set in hardware register but I don't know if >I can use the PHY interface as a simple FIFO. Actually, its the MAC you want to use, not the PHY. THere is a fair amount of overhead/complexity in the PHY layer which the MAC abstracts into "Send data stream/receive data stream". The V4-FX Tri-mode MAC can be accessed in a raw mode, without the powerPC. You want to use the raw client MAC interface to do this sending. See the users guide for this: http://direct.xilinx.com/bvdocs/userguides/ug074.pdf (starting at page 33) It's not that hard (it's VERY similar to the raw client GEMAC core that xilinx has available: For sending, you have a data valid signal, you get a data aack signal and you start clocking the data a byte at a time. Likewise, for receiving, you get a data valid signal, you clock in the data a word at a time. If you are in full duplex mode, you don't even have to worry about collisions, just send the data. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 88654
On Mon, 15 Aug 2005 03:21:49 +0200, Tullio Grassi <tgrassi@mail.cern.ch> wrote: >my understanding of verilog is that the code below is umbigous, >> always @(posedge clk) begin >> out_reg <= 2'd0; // Default value >> if (condition_1) >> out_reg <= 2'd1; >> if (condition_2) >> out_reg <= 2'd2; >> end >so it is a bad practice anyway, with or without delays. >The reason of the ambiguity is that assignements are >analyzed in parallel, so if condition 2 is true, you >don't know if the synthezaizer implemented > out_reg <= 2'd0; >or > out_reg <= 2'd2; This is completely untrue. Signal updates scheduled by nonblocking assignments *for a given moment of time* are performed in the same order in which the assignments were executed. I stand by my statement that this is "a useful synthesis idiom" provided you don't make the mistake of adding delays to the assignments. -- Jonathan BromleyArticle: 88655
fahadislam2002 wrote: > hi... > i m using spartan-2 ......... and have designed a very simple > vga controller on it ...... now i wanna interface an external ram > with it .......... i m available only a sram of 32 kbit * 8 = 256 kb > memory which is not dual port........ > i wanna store 640*480 pixels data on it ... as i need > only 8 colors ...so 3 bits for each pixel ... You don't have enough memory for a direct pixel array so you're going to have to do something else, like maybe RLE compression. Another thing you could do is make a tiled controller, similar to that used by some 8-bit computers of the 80s, and even things like the Nintendo Gameboy Advance. View your 640x480 screen as an array of 80x60 tiles, each one being 8x8 pixels. Your screen is now a tile array. Each array entry is a 2 byte tile index, so thats 80x60x2 = 9600 bytes. This leaves ~23K bytes for tile data. A tile is 8 pixels wide @ 3-bits per pixel = 24 bits (3 bytes). A tile is 8 pixels high @ 3-bytes per row = 24 bytes / tile. So your 32K byte memory can store the main tile array plus 965 tiles. That's pretty good - it can give the illusion of a full bitmapped display until the screen gets too busy. The Gameboy Advance allows tiles to be horizontally and vertically flipped (using two control bits in the tile index) which improves shareability even more, at the expense of more complicated scan-out. Good luck. Paul.Article: 88656
Paul Marciano wrote: > So your 32K byte memory can store the main tile array plus 965 tiles. > That's pretty good - it can give the illusion of a full bitmapped > display until the screen gets too busy. Just to continue on this thought for a bit. Every 8 VGA rows you will read in a new line out of the tile array. Each row is 80 bytes x 85ns = 6.8us. For each entry in the tile row, read the tile data into a block RAM. You'll need 80 x 3 x 8 = 1920 bytes of block RAM (or 15K-bits). The smallest Spartan 2 has 16K-bits. Each tile is 24 bytes, giving 24 x 80 x 85ns = 163.2us to read them all. >From this you can generate 640 x 8 VGA pixels without any further external memory accesses. 640x480@60Hz = 32us/row, so you're generating (8 x 32us) 256us of screen information using 170us of memory access time, assuming zero idle time. This leaves 33% SRAM bandwidth for CPU writes (perfect case timing). Some 8-bit micros of days gone by would assert WAIT (or equivalent CPU signal) to pause the processor during memory access conflicts. That might be applicable in this context. If you want to get more sophisticated, for a given tile array row, only read the tile data once. So if your tile array uses tile #100 three times, don't read the tile #100's data three times - only read it once. For sophistication++ view the block-RAM tile data as an LRU cache, and only populate tiles you haven't already got or are dirty (snoop CPU writes) and only retire tiles you're not going to use in the current tile array row. Good luck. Paul.Article: 88657
Assuming you already know some C++, "SystemC from the Ground Up" by Black and Donovan is pretty good. Others also show up when searching for "SystemC" at Amazon.com.Article: 88658
Paul Marciano wrote: > Paul Marciano wrote: > Just to continue on this thought for a bit. > Every 8 VGA rows you will read in a new line out of the tile array. > Each row is 80 bytes x 85ns = 6.8us. That's 80 x 2 bytes x 85ns = 13.6us. > For each entry in the tile row, read the tile data into a block RAM. > You'll need 80 x 3 x 8 = 1920 bytes of block RAM (or 15K-bits). The > smallest Spartan 2 has 16K-bits. If you were to implement this verbatim you'd need twice the block RAM, as you're reading in tile row + 1 data whilst still generating pixels from the current tile data. Also check your clock. 640x480x60Hz uses a 25MHz pixel clock. The RAM you mentioned has an 85ns (not 80ns) access time. If you're synchronous to the pixel clock your RAM cycles will have to be 120ns... which isn't good. Use a more appropriate core clock to minimize RAM access time and, if it's not a multiple of the pixel clock, remember a FIFO across the clock domains. You will also get memory access collisions when you want to read data from the RAM whilst the CPU is already in the middile of an access cycle. More fun to deal with. That's my last word on the matter (honest). Paul.Article: 88659
I’m wondering what sort of approach I should have in coding a bigger-than-one-entity-system. The system is going to use an FPGA to get sample data from two different kinds of AD-converters (6 + 3 A/D-converters in total). Two different LP-filters to filter the signals. An SPI-interface to all send all the data from the FPGA to the next system. Should I have a single state machine controlling all the different entities? Or should I have some form of signal between the different blocks that determines the dataflow?Article: 88660
<Terradestroyer@gmail.com> wrote in message news:1124894447.988350.229270@g43g2000cwa.googlegroups.com > I'm working on an fpga program to write to hard drives and so far I've > been pretty successful with the exception of a drive in the class I > want to use. > > The project involves high speed data storage upwards of 30-40 MB/s per > drive. Currently I have PIO transfer working on 3 out of 4 drives. An > old 730mb (ata2 compatible I think), a 4.3gb (ata 3 compatible), a > 6.4gb (ata 5 compatible), and a newer WD 80gb (ata 6 compatible). > > Problem is all the drives will recieve the data when I check sectors > except the 80gb drive. Does anyone know if this is because the drive > might be starting up in a udma mode and not accepting PIO commands? > Only the DIOR, DIOW, CS, DA, and lower 8 bits are connected to the fpga > - so could the 80gb be looking for another single or something? Any > ideas? You did off course check that the above signals don't have alternate functions in UDMA mode, right? > > Thank you, > KeithArticle: 88661
Hello, The approach is deppending on your application, FPGA resources, maximum throughput. One alternative might be runing everything at one clock (some high-speed clock), do one state machine which takes care of every entity one-by-one, while reading simultaneously from all the entities and buffering the data. Vladislav "Bubba" <blabla@bredband.net> wrote in message news:430cc4ab$0$18647$14726298@news.sunsite.dk... > I'm wondering what sort of approach I should have in coding a > bigger-than-one-entity-system. > > > > The system is going to use an FPGA to get sample data from two different > kinds of AD-converters (6 + 3 A/D-converters in total). Two different > LP-filters to filter the signals. An SPI-interface to all send all the > data > from the FPGA to the next system. > > > > Should I have a single state machine controlling all the different > entities? > Or should I have some form of signal between the different blocks that > determines the dataflow? > >Article: 88662
> > Personally, I'm surprised Microsoft included the piece of junk that is > Hyperterminal in Windows; there were far better choices! I also find it > incredible that Hilgraeve had the audacity to stick an advertisement for > the > full version of their product into it -- yeah, if the stripped-down > version > works so poorly, I'd really want to risk using a full blown version! > I would have fully agreed an hour ago. However, today I was so frustrated about the broken scroll-buffer that I checked Hilgraeves homepage (did anyone other ever did that?): There is a free update ("personal edition") that at least fixes this bug... As I have downloaded it only about 10 minutes ago I do not know about the other bugs, but it can't be worse then before... BTW: In the XP-HyperTerm there is a note about (C) Microsoft, parts (c) by Hilgraeve, while the update (and I also believe the original Win 95-HyperTerm) is only (c) Hilgraeve. So I get the feeling, that we were all partly blaming the wrong company for that piece of junk ;-) ThomasArticle: 88663
Bubba wrote: > I’m wondering what sort of approach I should have in coding a > bigger-than-one-entity-system. Break up entities based on reuse, complexity or testbench. Start with a two-level top design entity for each FPGA containing only 1.instances for reused/purchased modules 2.components for the unwritten design entities and 3.signals as needed for local interconnect. > Should I have a single state machine controlling all the different entities? No. In a two-level design, each process has access to the top port pins via the instance port map. Each process also has architecture signals and local variables in scope. If this seems constraining, the entity/process may have to cover more outputs. > Or should I have some form of signal between the different blocks that > determines the dataflow? The cleanest partition has each entity drive it's own set of output pins via the port map. If each module has cpu registers, a small signal bus is probably indicated to minimize the signal wiring. For deeply pipelined designs, you may need to break this up with some entities connected in series via architecture signals. -- Mike Treseler.Article: 88664
Vlad, Antti is alive, and very well. He has chosen not to post here, and I respect that. He is in communications with Xilinx, and we are working together. Thank you for your kind comments, Austin Vladislav Muravin wrote: > Austin, > > First, thank you for the prompt response; now i understand the picture. > > Well.................. I have pretty similar personality to Antti's (not > entirely similar :) !!! ) > So, statistically speaking, your explanation of your response whatever it > was (let's not call it apology, I hate this word) should have made a > difference and I would let Antti spend a few days and finally chill down. > > And if Antti still reads this post, I would advise following of my "life > guidelines", which is "Try judging people not by mistakes they make, but > whether they can realize && acknowledge && let you know that they understand > they made one". After all, we are people first, and only then, > Angineers............. > > Best regards. > > Sincerely, > Vladislav > > > > "Austin Lesea" <austin@xilinx.com> wrote in message > news:cy7Ne.3108$Z87.1391@newssvr14.news.prodigy.com... > >>Vlad, >> >>No secret, it was I who offended Antti. I have apologized to him >>personnally. I did not intend to slight him in any way. In fact, his >>comments have been, and continue to be, very valuable to Xilinx. >> >>I respect Antti, if and when he feels comfortable with posting again, or >>when he feels it may be useful to post, it will be up to him to decide. I >>can live with that. Everyone here has the right to post, or not to post, >>and if they post, to post what they will. >> >>It takes time and energy to post here, and some people get things done >>without the bother. For example, the largest source of email addresses >>for spam are harvested from newsgroups (unfortunately). >> >>I reserve my right to reply to postings as well. I also have the best >>email filtering imaginable (three levels), and our internet service >>provider is daily driven crazy by the number of spam emails they have to >>block for Peter and me. >> >>I never intended to insult or offend anyone. >> >>Austin >> >> >>Vladislav Muravin wrote: >> >> >>>Antti, >>> >>>Two things: >>> >>>(*) What's the story with 5 bucks? >>>(**) I could not find this reply && so can someone explain what the hell >>>is going here. This "someone" should be (Antti || Xilinx). >>> >>>Thanks >>> >>>Vladislav >>> >>>"Antti Lukats" <antti@openchip.org> wrote in message >>>news:ddt6pp$rjq$01$1@news.t-online.com... >>> >>> >>>>Hi all >>>> >>>>I am regret to inform you all that this the last time I either post or >>>>reply to comp.arch.fpga newsgroup. This decision was triggered by an >>>>reply from an Xilinx employee to one of my postings. If someone wants to >>>>look up that posting then its around the sentence: "This may have been a >>>>mistake" - I do understand that I may have understand the original >>>>intentions of that posting and that sentence and the context wrong, but >>>>that doesnt make any difference to my decision which is final. I will not >>>>discuss this matter in public or make any comments on it. A small >>>>explanation about the reasoning and background of my decision is >>>>available but not for free and not for quoting or republishing by any >>>>media. >>>> >>>>http://shop.openchip.org/shop/product_info.php?cPath=28_29&products_id=36 >>>> >>>>Antti Lukats, posted to comp.arch.fpga at 1900PM on 16 August 2005 >>>> >>>>my final smile :) to all of you. >>>> >>>> >>>> >>> >>> >Article: 88665
echoisme wrote: > In Xilinx application Note XAPP501, there are two phrase --- > "configuring Xilinx FPGAs" and "programming CPLDs and PROMs" > i am not a english-speaker, and cann't fully understand the difference > of the two words "configuring" and "programming", > anybody can explain that for me? thanks a lot! > For historical reasons only, Xilinx has referred to the process by which configuration data is loaded into FPGAs as "configuring". Xilinx has similarly referred to the process by which configuration data is loaded into a PROM or a CPLD as "programming". The typical rationale given was that because one is a volatile medium (FPGA) and the other a non-volatile medium (PROM and CPLD) and their programmed behavior different in that one loses its memory after power off and the other doesn't; so the "action" describing the programming operation should be different, too. Most people do not make that linguistic distinction and still lead full and complete lives.Article: 88666
> Assuming that the clk shifter is getting clkin from the divider (which > would be normal), then you should take the locked signal from the clock > divider, invert it, and use that to reset the clk shifter. The result is > that the clock shifter is held in reset until the divider has locked. Although I have used the DCMs on Spartan-3, I haven't had any experience of cascading them yet. However, I do remember that when cascading CLKDLL primitives in Spartan-2, it was recommended to delay the release from reset of a subsequent DLL until some clock cycles after the preceding one had locked, perhaps feeding the /LOCKED signal through an SRL16. While I'm pretty sure that this was a workaround for an errata in the Spartan-II and should not necessarily be required here, it is worth bearing in mind if you have any difficulties (and one or two spare LUTs!) Richard.Article: 88667
Hi, No the number of IOB's correspond to the design (if mean that). So far I can't explain where is this unrelated logic appear. The problem now is when I have an array (design has a regular structure)of N units it map everything alright, but when I add one, i.e. N+1- it is appear that some of the previously well mapped elements appear to be bigger :-/. I assumed MAP-er tries to fit some unrelated logic into occupied slices, but first of all the AREA_GROUP is constrained as PLACE=CLOSE, and second there are still plenty of slices. So I am really desperate now. > Is it adding an IO Buffer or something like that? > > "Alex" <al.lopich@gmail.com> wrote in message > news:opsvyrpqwuuctc33@d48mko2.ee.umist.ac.uk... >> Hi Marc, >> >> I have checked the MAP reports of both design and here is the >> difference: >> For the Element B: >> >> AREA_GROUP AG_CU >> RANGE: SLICE_X6Y2:SLICE_X8Y1,SLICE_X5Y1:SLICE_X5Y1 >> COMPRESSION: 100 >> AREA GROUP Logic Utilization: >> Total Number of Slice Registers: 6 out of 14 42% >> Number used as Flip Flops: 2 >> Number used as Latches: 4 >> Logic Distribution: >> Number of occupied Slices: 7 out of >> 7 100% >> Number Slices used containing only related logic: 4 out of >> 7 57% >> Number Slices used containing unrelated logic: 3 out of >> 7 42% >> *See NOTES below Design Summary for an explanation of the effects >> of >> unrelated logic >> Total Number 4 input LUTs: 12 out of 14 85% >> Number used as logic: 12 >> >> For the element A: >> >> AREA_GROUP AG_P00__CU >> RANGE: SLICE_X6Y2:SLICE_X8Y1,SLICE_X5Y1:SLICE_X5Y1 >> COMPRESSION: 100 >> AREA GROUP Logic Utilization: >> Total Number of Slice Registers: 6 out of 14 42% >> Number used as Flip Flops: 2 >> Number used as Latches: 4 >> Logic Distribution: >> Number of occupied Slices: 8 out of 7 114% (OVERMAPPED) >> Number Slices used containing only related logic: 4 out of >> 8 50% >> Number Slices used containing unrelated logic: 4 out of >> 8 50% >> *See NOTES below Design Summary for an explanation of the effects >> of >> unrelated logic >> Total Number 4 input LUTs: 13 out of 14 92% >> Number used as logic: 13 >> >> >> So now we can see that the amount of unrelated logic has increased!! >> >> For the element C itself with the same constraints the data is: >> Logic Distribution: >> Number of occupied Slices: 7 out of >> 13,312 >> 1% >> Number of Slices containing only related logic: 5 out of >> 7 71% >> Number of Slices containing unrelated logic: 2 out of >> 7 28% >> >> I don't really see the the reason for appearing of the additional logic >> at >> the "A" >> level of hierarchy. The PLACE constrainis is set to CLOSED. >> :( >> >> >> Alex > > -- AlexArticle: 88668
"Hal Murray" <hmurray@suespammers.org> wrote in message news:Q5GdnZukHvCksZHeRVn-1Q@megapath.net... > >yes, if you buy it from xilinx, you will get all of it. but if you buy >>it from digilent, you will not get the evaluation software. im not sure >>whether im getting the other parts like JTAG cable and power adaptor if >>i buy it from digilent. I prefer to buy it from digilent, because i >>want to have a better device with atleast 400K gates. Im not sure >>whether the starter kit is available with a better device. > > I got my starter kit from Digilent because I wanted one of their > other boards too. It came with wall wart and programming cable. > I pulled the software of the net and didn't pay any attention > to whatever they shipped. > > It's a great little board, especially at the price. > > One thing to keep in mind. There aren't many ground pins on > the expansion connectors. Don't expect them to work if you > need to flap lots of pins at high speed. > > Earlier you asked aboue the USB card. Usually, Digilent has > lots of info for their boards available on their web. Not much > available for this one. Or maybe I just didn't look in the > right place. I'd call/email before depending on it. > > The blurb that is available has the Cypress chip number. > Have you looked up the specs on that chip? Can it do > what you want? Are you prepared to write code for it > and/or will their code do what you need? > > I'd guess that the USB chip is programmed and/or wired > so that it can download the FPGA over the USB cable if you > plug it into the right connector, but it doesn't say that > so maybe that's not what they did. (Seems like a neat > thing to brag about so I'm assuming they would say so if > they had it working.) I have one of these USB adapters from Digilent. It is a programmable Cypress USB controller that can be used to configure the FPGA or serial PROM. However, they do not provide the source to the code or binary file required to program this device yourself.... too bad as I would have loved to have incorporated this into my final design. -- Ed > > Ah.. Here is the info I was expecting: > http://www.digilentinc.com/products/Documentation.cfm > Looks like they forgot the wrapper page from the page > full of I/O cards. > > Yup, says you can download and talk to a PC. > > -- > The suespammers.org mail server is located in California. So are all my > other mailboxes. Please do not send unsolicited bulk e-mail or > unsolicited > commercial e-mail to my suespammers.org address or any of my other > addresses. > These are my opinions, not necessarily my employer's. I hate spam. >Article: 88669
Hi Brandon, What is the signal you are analysing/filtering? Presuamably you have ruled out decimation to get the rate down? Regards AndrewArticle: 88670
thanks, everybody then what is difference between "reconfigurable" and "programmable"? i am really confused with them for a long time!Article: 88671
Hey to all, Background information: I am doing a project which has a single ppc and a specialize DES core in a Virtex 2 Pro using EDk 7.1 aas design tool. The situation is concerning the drivers generated by the EDK 7.1 for testing the core functionality in software. The EDK 7.1 generates a driver and with this driver comes a self test (unit test) for the driver which tests the register r/w, the fifos r/w and the DMA transfers in my case all the tests except for the DMA seem to worked fine. For some reason the DMA test doesn't give me the expected output. Here is a snippet of the code: Note: This Test is for Single DES CBC Decrypt with Key = 0123456789ABCDEF and IV = 1234567890ABCDEF Xuint8 SrcBuffer[MULTI_DES_SELFTEST_BUFSIZE] Xuint8 DstBuffer[MULTI_DES_SELFTEST_BUFSIZE] // SrcBuffer is initialize via a loop to contain '0xE5C7CDDE872BF27C' for( Index = 0; Index < MULTI_DES_SELFTEST_BUFSIZE; Index + 8) { SrcBuffer[ Index ] = 0xE5; SrcBuffer[ Index + 1 ] = 0xC7; SrcBuffer[ Index + 2 ] = 0xCD; SrcBuffer[ Index + 3 ] = 0xDE; SrcBuffer[ Index + 4 ] = 0x87; SrcBuffer[ Index + 5 ] = 0x2B; SrcBuffer[ Index + 6 ] = 0xF2; SrcBuffer[ Index + 7 ] = 0x7C; } // THe DstBuffer is initialize to zeroes ... // The DMA is reset MULTI_DES_mResetDMA0(baseaddr); // The DMA setup MULTI_DES_mSetDMA0Control(baseaddr, DMA_SINC_MASK | DMA_LOCAL_MASK ); // DMA transfer MULTI_DES_DMA0Transfer( baseaddr, baseaddr + MULTI_DES_WRFIFO_DATA_OFFSET, MULTI_DES_SELTEST_BUFSIZE); but when I look at the results there are nothing like the expected value: '0x4E6F772069732074' Thanks, NoelArticle: 88672
Sounds like you are making progress. Have you simulated the design as I suggested a few weeks ago? Paul el_boricua wrote: > > Hey to all, > > Background information: > I am doing a project which has a single ppc and a specialize > DES core in a Virtex 2 Pro using EDk 7.1 aas design tool. The situation > is concerning the drivers generated by the EDK 7.1 for testing the core > functionality in software. > The EDK 7.1 generates a driver and with this driver comes a self test > (unit test) for the driver which tests the register r/w, the fifos r/w > and the DMA transfers in my case all the tests except for the DMA seem > to worked fine. > For some reason the DMA test doesn't give me the expected output. Here > is a snippet of the code: > > Note: This Test is for Single DES CBC Decrypt with Key = > 0123456789ABCDEF > and IV = 1234567890ABCDEF > > Xuint8 SrcBuffer[MULTI_DES_SELFTEST_BUFSIZE] > Xuint8 DstBuffer[MULTI_DES_SELFTEST_BUFSIZE] > > // SrcBuffer is initialize via a loop to contain '0xE5C7CDDE872BF27C' > > for( Index = 0; Index < MULTI_DES_SELFTEST_BUFSIZE; Index + 8) > { > SrcBuffer[ Index ] = 0xE5; > SrcBuffer[ Index + 1 ] = 0xC7; > SrcBuffer[ Index + 2 ] = 0xCD; > SrcBuffer[ Index + 3 ] = 0xDE; > SrcBuffer[ Index + 4 ] = 0x87; > SrcBuffer[ Index + 5 ] = 0x2B; > SrcBuffer[ Index + 6 ] = 0xF2; > SrcBuffer[ Index + 7 ] = 0x7C; > } > // THe DstBuffer is initialize to zeroes > ... > > // The DMA is reset > MULTI_DES_mResetDMA0(baseaddr); > > // The DMA setup > MULTI_DES_mSetDMA0Control(baseaddr, DMA_SINC_MASK | DMA_LOCAL_MASK ); > > // DMA transfer > MULTI_DES_DMA0Transfer( baseaddr, baseaddr + > MULTI_DES_WRFIFO_DATA_OFFSET, > MULTI_DES_SELTEST_BUFSIZE); > > but when I look at the results there are nothing like the expected > value: > '0x4E6F772069732074' > > Thanks, > NoelArticle: 88673
Hello, I recentally purchased a Stratix II (60) DSP Dev Board (from Altera) and I have been having a bit of trouble getting the ADC to work correctly and I was wondering is there was anyone therer that had experience with this board. I am able to get it to work when the clk is set to 100MHZ, but is I use a PLL to run the clk at say 80MHz then the data that I read from the ADC (also clocked at 80MHz from the same PLL output) is not clean. i.e. it is similar to the signal I would expect however it has spikes in it everywhere. I assume this is a clock skew issue or something like that. I have found that if I use a seperate PLL output to drive the ADC clk then I apply a 180 degree phase shift to that output then my data looks clean. So the questions I have are: 1) It would appear that you need to apply a phase shift on the adc clock output to account for clock skew (or for some other reason). How do you decide by how much to phase shift the clock? I chose 180 degrees at random and it seems to work, however I am concerned that this was not a very academic approach and I could be near a threshold of working / not working. 2) It appears that my data is inverted, does anyone know if the ADC's on this board are active high or active low? I had assumed active high as there is no _n suffix next to the pin name, but my data does appear to be upside down. Regards Paul SolomonArticle: 88674
"echoisme" <ghy@eyou.com> wrote in message news:1124940523.012775.76130@g44g2000cwa.googlegroups.com... > thanks, everybody > then what is difference between "reconfigurable" and "programmable"? > i am really confused with them for a long time! > In the context we're discussing, "reconfigurable" implies the device can be programmed more than once. "Programmable" implies it can be configured at least once. Cheers, Syms. p.s. So, "configurable" means the same as "programmable". Adding "re" at the beginning of either word means you can do it more than once!
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