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
Symon wrote: > Hi Pete, > There's a guy here on CAF who's something to do with FpgaC. > http://fpgac.sourceforge.net/ > Perhaps you could ask him to help implement the COS function, he seems to be > at a loose end! ;-) Actually it would be a fun project, and down the line of where we are headed long term anyway. The FpgaC project has a way to go to be fully featured, but it seems that this project could be done as a series of user written functions with little trouble. As far as being a loose end, I'll take that as a complement :) Life is very disappointing when you sit around a wait for things to happen. Stirring things up a little is sometimes required to shake the cobwebs off that are holding everyone stuck in place.Article: 96001
I am unfamiliar with the Atmel part in question but am quite certain that iMPACT is OK with instruction register lengths down to 2 bits (which is the minimum allowed by the standard). My cursory examination of the Atmel data sheets indicates that the part has 2 pins that control the test modes - a TST (which seems to enable some manufacturing modes so it must always be low) and the JTAGSEL (which seems to be temperamental in that a reset is required between toggles). I'm wondering if the FPGA pins are connected to either of these pins and perhaps interfering with the boundary-scan chain during configuration? I'm suspicious of some interaction of that sort, if not between the FPGA and those pins, perhaps some other ones - or perhaps an interaction between the processor pins and PROG or the FPGA mode pins during configuration. Idle thoughts... Glad you have a work-around. Antti Lukats wrote: > "John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag > news:88sCf.1959$wk5.1266@news02.roc.ny... >> "Antti Lukats" <antti@openchip.org> wrote in message >> news:drd04j$iu7$01$1@news.t-online.com... >>> simple JTAG Chain: Atmel-SAM7 ARM --> XC3S1500 --> XC9572XL >>> >>> attempt to configure FPGA with Impact, done not high configuration status >>> register = 0000 >>> attempt to program PLD seems to stall forever clicking abort and waiting >>> makes impact again responsive with failure to program >>> >>> changing the BSDL file makes the chain order to get messed, attempt to re >>> order the device by mouse drag and drop causes impact to self terminate. >>> >>> are there any issues with non Xilinx device in JTAG chain with impact >>> 8.1? >>> >>> any help really welcome, I do not have time to open a webcase as I must >>> have the board up and running til early next week. >>> >>> (the new bugs are entered in bugtrackter http://bugs.xilant.com ) >>> >>> -- >>> Antti Lukats >> >> I don't know why I had problems but we worked around them. The Spartan-3 >> on my board was the first in the JTAG chain followed by 4 other non-Xilinx >> devices. On the new rev of board we connected the FPGA so it could be >> isolated from the other devices for Chipscope-like debug (Synplify's >> Identify product) by swapping a couple resistors. Without the isolation >> from the chain, when I tried to get the debugger to communicate the board >> would reset. There may have been troubles with 1) another chip resetting >> the system when toggled through the jtag sequence with or without TRST >> applied properly to that device or 2) unexpected voltages on the soft >> reset signal sourced by the FPGA causing a system reset. Bottom line: I >> couldn't get the JTAG port up & running for debug on the first generation >> of board. Thankfully the Identify tool allows a "custom" port that's a >> JTAG emulator that I ported out to 4 test points. >> > thanks John, > > well I have a workaround also, the chip that makes impact to freeze is > Atmel ARM7SAM, with 2 different JTAG inside (selectable by ext pin at > powerup) > one of them has 4 bit IR lenght (ARM Embedded ICE) the other (boundary scan) > 3 bit IR > length. So if the ARMice is chain all is OK. if the ARM boundary scan then > impact freezes. > > So my guess is that Impact can not handle JTAG devices with IR register > lenght less than 4 > but I may be wrong of course. > > Anyway the workaround for us was to remove the pullup on JTAGSEL of the ARM > SAM > and those make the ARM IR register 4 bit long, then impact can work without > problems > >Article: 96002
johnp wrote:
>
> I don't see any documentation on the DIFF_OUT buffers you mention.
> Do you have any info on them or pointers to doc?
>
All the V2-ish differential input buffers have a complementary output
available, that can be used to create a 180 degree clock without
needing a DCM.
These can also be used just to invert a differential input without
needing any other logic (or board cuts & jumps).
Look at the DIFFS component in fpga_editor to see what's going on;
besides the normal 'phantom' route from the DIFFS to the DIFFM,
there's also a route from the DIFFM to a differential receiver in the
DIFFS that outputs the complement signal.
I first spotted these when they showed up in early versions of
XAPP622 as a hard macro.
Support & tool bugs for these have varied version to version,
see Answer Record 21958 for recent problems.
I've banged into various other problems in using them over the years;
if I get a chance this weekend, I'll try to dig up some old webcase
code showing how to create one out of two normal IBUF{G}DS's as
a work around.
These can be used on regular IOB inputs as well as global clock
inputs, but you've generally needed to LOC the global input buffer
and bufg's to allowed sites to get this to work.
search for
ibufgds_diff_out
ibufds_diff_out
Brian
Article: 96003> Without knowing the particular package you use, but having > written a fullblown tcp/ip implementation for PPC, I would say > that either your client is messed up (does not send the right > ack segments so you have to manually send them) or, more > likely, some of the segments the server sends after the first > one get lost and thus the client never sends an ACK. > If the IP layer is doing fragmentation/defragmentation, this > could be a place to look at. Also, I have encountered similarH > behaviour when I have had simply physical layer problems > (too many lost packets), but in most cases the TCP retransmission > would take care of that. > Hope this is of some help... > > Dimiter > > ------------------------------------------------------ > Dimiter Popoff Transgalactic Instruments > > http://www.tgi-sci.com > ------------------------------------------------------ > Hi Dimiter and thanks for your input, The client is made in .NET by a colleague, and I don't think that the socket package is behaving badly. I have also tried to connect with a terminal program to my server as well with the same results. I have been sniffing the communication with Etherreal and what happens is that the server starts listening on a certain port (i.e. accept is polled until a client connects). The initial SYN and ACKs are carried out correctly and the server is waiting for the client to send it some sort of commando. This is done in the same loop as accept on the established connection. When the client tells the server to start sending data a xilsock_send command is added to the loop. That is, each looping does first an accept to check for packets, second a parsing of the available data (if any), and finally a sending of data. In Etherreal I have seen that the first data packet is sent successfully followed by an ACK from the client, the second data packet is sent too (with the correct seqno and ackno), but the ACK to that data packet is a duplicate of the first ACK (thus with the wrong ackno). The server then tries to retransmit the failing packet without success... I wouldn't be surprised if my server application is lacking some feature, but I really can't see what it is. Johan (from the living room couch on a Friday night) -- ----------------------------------------------- Johan Bernspång, xjohbex@xfoix.se Research engineer Swedish Defence Research Agency - FOI Division of Command & Control Systems Department of Electronic Warfare Systems www.foi.se Please remove the x's in the email address if replying to me personally. -----------------------------------------------Article: 96004
"Neil Glenn Jacobson" <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> schrieb im Newsbeitrag news:dre15b$ngj6@cliff.xsj.xilinx.com... >I am unfamiliar with the Atmel part in question but am quite certain that >iMPACT is OK with instruction register lengths down to 2 bits (which is the >minimum allowed by the standard). My cursory examination of the Atmel data >sheets indicates that the part has 2 pins that control the test modes - a >TST (which seems to enable some manufacturing modes so it must always be >low) and the JTAGSEL (which seems to be temperamental in that a reset is >required between toggles). I'm wondering if the FPGA pins are connected to >either of these pins and perhaps interfering with the boundary-scan chain >during configuration? I'm suspicious of some interaction of that sort, if >not between the FPGA and those pins, perhaps some other ones - or perhaps >an interaction between the processor pins and PROG or the FPGA mode pins >during configuration. > > Idle thoughts... > > Glad you have a work-around. > yes I have a workaround that is ok so far, but for production test I need correct solution too. JTAGSEL is connected to PLD, everything was fine until I changed the JTAGSEL value by reprogramming the PLD, afer that impact just frozed while trying to reporgram the PLD. so no matter the the reason for the fail, there is some sort of bug with impact as any kind of wrong behaviour of the JTAG chain during programming should not cause impact to freeze. my guess about the 3 IR bits not supported was based on fact that as soon as reverted the ARM into ICE mode with longer IR register everything started to work again. the ARM has been unprogrammed all the time, only change to revert the chain useable was disconnecting JTAGSEL - as JTAGSEL is only latched on power up the connection to PLD can not change the scan chain config once powered. well FPGA PROG_B is also connected to the PLD, but it should not matter as the signal that made the difference was JTAGSEL on ARM, no matter the FPGA connections it should not prevent the PLD from being programmed - as long as ARM IR chain doesnt chain its length during runtime. I will investigate it a little more when the board is otherwise fully tested. AnttiArticle: 96005
Hi all Lattice is close to have some of the new FPGA products to be announced some of them in the next few weeks time (probably at embedded in Nurnberg already) no details known but something in the range of Virtex-4 is coming (on high speed SERDES there are no immediate plans for support over 6Gbit) MachXO is now all family in production, to my surprise (or maybe I had forgotten) the full MacXO family is available in super compact 0.5mm pitch BGA 8 by 8 mm thats really neat, 8by8mm (only 1m larger then the CSP48 !), single supply 1.8 - 3.3 up to 2 PLL and 3 BRAMs, distributed RAM, and fabric faster than the LatticeXP also coming are are sub 3 (and even sub 2) USD low cost small package versions of the power supply monitor and supervisory circuits AnttiArticle: 96006
Antti Lukats wrote: > Lattice is close to have some of the new FPGA products to be announced > some of them in the next few weeks time (probably at embedded in Nurnberg > already) > no details known but something in the range of Virtex-4 is coming > (on high speed SERDES there are no immediate plans for support over 6Gbit) Wow ... totally cool. This market is going to have lots of viable players soon :)Article: 96007
Johan Bernspang wrote: > ...... In Etherreal > I have seen that the first data packet is sent successfully followed by > an ACK from the client, the second data packet is sent too (with the > correct seqno and ackno), but the ACK to that data packet is a duplicate > of the first ACK (thus with the wrong ackno). The server then tries to > retransmit the failing packet without success... I wouldn't be surprised > if my server application is lacking some feature, but I really can't see > what it is. > > Johan (from the living room couch on a Friday night) > Hi Johan, this really sounds like the segment you call "second packet" is either bad when being sent or lost at the receiving side, thus the server retransmits. Since it does have the right seq and ack numbers, the reason must be elsewhere - could be the tcp checksum, IP header checksum, some other bad field, damaged IP, misrouted, you name it. Please feel free to contact me priavately if you feel like it, I'd be happy to look into the IP packet exchange (but I do think it will just take you another hour or so of thorough inspection and you'll figure it out, these things are bulky yet pretty straight forward). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------Article: 96008
hi Thanks for replying iam using microblaze for first time so please bear with my questions iam using data width for flash device as 8 but does opb emc support data width matching for flash devices? if it does support, updating the settings of system.mhs file takes care of it or do i need to change any other settings wat values should i use for these parameters C_THZCE_PS_MEM_0, C_TWP_PS_MEM_0 ,C_TCEDV_PS_MEM_0, C_TAVDV_PS_MEM_0, C_TWC_PS_MEM_0Article: 96009
Sean Durkin schrieb: > The signal I get as output from the IBUFDS I can feed into an ISERDES. > Since one ISERDES can only give me 6 bits in parallel, I need to use two > ISERDES in Master-/Slave-mode, but then they can only give me 10bits > instead of the 12 I actually get from the ADCs. So it's not going to > work that way. Why? An ethernet frame is hundreds of bits and you can still receive it with an ISERDES. Use a 1:6 serdes and continue to process your data stream in chunks of 6-bit at a convenient rate of 80 MHz. You can add logic in the FPGA-fabric that immediately converts the stream to 12-bits at 40MHz. But probably you get a smaller circuit when you do all your signal processing 6-bit-nibble serial at 80MHz. This issue came up in this newsgroup a few times before. Somehow everybody immediatly recognizes that a 16-bit entity can be split up into two bytes of 8-bits. But as soon as the numbers change a little apparently it becomes less obvious. Kolja SulimmaArticle: 96010
Antti Lukats wrote: > "Neil Glenn Jacobson" <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> schrieb im > Newsbeitrag news:dre15b$ngj6@cliff.xsj.xilinx.com... >> I am unfamiliar with the Atmel part in question but am quite certain that >> iMPACT is OK with instruction register lengths down to 2 bits (which is the >> minimum allowed by the standard). My cursory examination of the Atmel data >> sheets indicates that the part has 2 pins that control the test modes - a >> TST (which seems to enable some manufacturing modes so it must always be >> low) and the JTAGSEL (which seems to be temperamental in that a reset is >> required between toggles). I'm wondering if the FPGA pins are connected to >> either of these pins and perhaps interfering with the boundary-scan chain >> during configuration? I'm suspicious of some interaction of that sort, if >> not between the FPGA and those pins, perhaps some other ones - or perhaps >> an interaction between the processor pins and PROG or the FPGA mode pins >> during configuration. >> >> Idle thoughts... >> >> Glad you have a work-around. >> > yes I have a workaround that is ok so far, but for production test I need > correct solution too. > > JTAGSEL is connected to PLD, everything was fine until I changed the JTAGSEL > value by reprogramming the PLD, afer that impact just frozed while trying to > reporgram the PLD. > > so no matter the the reason for the fail, there is some sort of bug with > impact as any kind of > wrong behaviour of the JTAG chain during programming should not cause impact > to freeze. > > my guess about the 3 IR bits not supported was based on fact that as soon > as reverted > the ARM into ICE mode with longer IR register everything started to work > again. the > ARM has been unprogrammed all the time, only change to revert the chain > useable > was disconnecting JTAGSEL - as JTAGSEL is only latched on power up the > connection > to PLD can not change the scan chain config once powered. > > well FPGA PROG_B is also connected to the PLD, but it should not matter as > the > signal that made the difference was JTAGSEL on ARM, no matter the FPGA > connections it should not prevent the PLD from being programmed - as long > as ARM IR chain doesnt chain its length during runtime. I will investigate > it > a little more when the board is otherwise fully tested. > > Antti > Hmm. Which PLD is involved here? I'm suspicious that iMPACT is not actually frozen but just taking a really long time to fail. If it is a 9500/XL/XV then these devices use polling to indicate when programming (or erasure) is complete. The device responds with a status to iMPACT to indicate success or failure. Some failure statuses mean keep trying - just wait longer. The wait time increase can quickly increase to minutes in certain failure situations. I am speculating that the PLD mucks with JTAGSEL doing something horrible to the boundary-scan chain, making the output look like the status that says "keep trying - just wait longer" and then you end up with this apparent "freeze". Bad behavior. Should fail more elegantly if that's what happening. That's my theory, anyway. > > > > > > > >Article: 96011
Antti Lukats wrote: > my guess about the 3 IR bits not supported was based on fact that as soon > as reverted > the ARM into ICE mode with longer IR register everything started to work > again. .. perhaps the Atmel device itself has Bypass problems in the other mode ? -jgArticle: 96012
Antti Lukats wrote: > Hi all > <snip> > also coming are are sub 3 (and even sub 2) USD low cost small package > versions > of the power supply monitor and supervisory circuits These needed to come down in price - at the silly prices they were, they were never going to hit mass support - just the odd VHDL designer who was unable to get a small uC and a couple of FETs to do the same thing. The newest tiny system uC, like the Tiny2313, newest ST7 lite, and Atmel LP216, are all in the 80c region, and you keep getting more for your 80-90c.... All Lattice needs now, is to work out how to turn a profit :) -jgArticle: 96013
Sean Durkin wrote:
>
> The signal I get as output from the IBUFDS I can feed into an ISERDES.
> Since one ISERDES can only give me 6 bits in parallel, I need to use two
> ISERDES in Master-/Slave-mode, but then they can only give me 10bits
> instead of the 12 I actually get from the ADCs. So it's not going to
> work that way.
>
Use the ISERDES setup you describe here to get 6 bits at a time.
Really quick pseudo code for a solution:
signal left : std_logic_vector ( 5 downto 0);
signal sample : std_logic_vector ( 11 downto 0);
if ( falling_edge( sample_clock ) ) then
left <= ISERDES_out(5 downto 0);
end if;
if ( rising_edge( sample_clock ) ) then
sample <= left && ISERDES_out(5 downto 0);
end if;
Sample clock needs to be properly phased to the ISERDES output, and a
timing constraint with 1/2 the period of sample_clock is placed between
ISERDES_out and the two destination registers. The tools will take it
from here.
Regards,
Erik.
---
Erik Widding
President
Birger Engineering, Inc.
(mail) 100 Boylston St #1070; Boston, MA 02116
(voice) 617.695.9233
(fax) 617.695.9234
(web) http://www.birger.com
Article: 96014John Adair wrote: > EDK 8.1 is available from late last week to existing customers by the > download mechanism. I just spoke to someone in Xilinx Customer Service, and she said that although they had expected the official release of EDK 8.1 to occur this past Monday, that apparently it did not, and she's not sure when it will be. The same thing happened with ISE 8.1; some customers were able to download it before the official release, but others were not. It seems reasonable to expect that the official release will occur soon. EricArticle: 96015
hutzelbutz <joachim.becker@imtek.uni-freiburg.de> wrote: > However, the command "hostid" gives the right value. So I did " sudo > hostname > /etc/hostid" to create the file and voila: ISE starts in 5 > seconds. I hope for Xilinx that it is possible to configure this filename. It is clearly unacceptable that a (more or less) simple userland application needs a system-wide configuration file. I agree for daemons or default-overrides like /etc/opera6rc, but not for a tool which might run without uid-0-interaction at all. Whoever has insisted on this filename should go back to the 90th and code Win95-applications when there was still no need to divide into user-related stuff (configuration, save files) and system installation. In other words: put your xilinx.ini in the windows directory ;) SCNR ;) -- mail: adi@thur.de http://adi.thur.de PGP: v2-key via keyserver Kein Kind ass das Pilzgericht, nur der Juergen, der muss wuergen.Article: 96016
Symon wrote: >The key insight is to use a latch (NOT a FF) to align the clock enables >in the rising and falling edge clock domains. The latches are fast enough >to meet the timing way beyond 480M, my stuff is working great at 622M. Alas, I swore off Xilinx latches after the Great Latch Inversion of '00 Brian p.s. Actually, it's not the actual latches I distrust; it's the software guys configuring the latches, having to interpret the latch enable sense when it's not properly documented in the datasheet. GoogleGroups "CLB latch clock inversion" from latch_bug1.txt: : For an active low latch in an EDIF input file, you get : the following results when tracing the clock signal through : the tool flow: : : tool stage XC4000EX derived Virtex Derived : ------------------------------------------------------- : EDIF in active low active low : MAP out CLK:CLKNOT CLK:CLK : EPIC display dot clock normal clock : SIMPRIM model X_INV -> X_LATCH X_INV -> X_LATCH : real HW transparent low transparent low : : note: X_LATCH SIMPRIM models are transparent highArticle: 96017
Hi Paul, Assuming that you have a personal project that utilizes PCI bus, I will recommend BDS XPCI PCI IP core we have developed. BDS XPCI PCI IP core is a Xilinx (TM) LogiCORE (TM) PCI compatible PCI IP core. We offer this PCI IP core for as little as $100 for non-commercial, non-profit, personal use. For more information, visit http://www.bracedesignsolutions.com. Kevin Brace Paul Marciano wrote: > John Adair wrote: > >>You might want to have a look at our product Raggedstone1. It has the much >>larger XC3S400-4FG456C part fitted. Programming cable is included and card >>can be used in a PCI slot or stand-alone with the optional PCI I/O Header. >>Details here http://www.enterpoint.co.uk/moelbryn/raggedstone1.html. > > > As a learner and experimenter I like the look of that board, but how > much does the Xilinx PCI core for the Spartan 3 cost? > > Paul. > -- Brace Design Solutions Xilinx (TM) LogiCORE (TM) PCI compatible BDS XPCI PCI IP core available for as little as $100 for non-commercial, non-profit, personal use. http://www.bracedesignsolutions.com Xilinx and LogiCORE are registered trademarks of Xilinx, Inc.Article: 96018
The PLD pins float during programming. Depending on the CPLD, it is typically pulled high, weakly, while the device is being programmed. You might want to install a strong pull-up on the JTAGSEL to hold it high during configuration and see if that helps things. If JTAGSEL floats low, you will be hosed - it appears. Again, not knowing which Atmel device you are using you may also find this instructive: http://www.atmel.com/dyn/products/faq_card.asp?faq_id=780 Neil Glenn Jacobson wrote: > Antti Lukats wrote: >> "Neil Glenn Jacobson" <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> >> schrieb im Newsbeitrag news:dre15b$ngj6@cliff.xsj.xilinx.com... >>> I am unfamiliar with the Atmel part in question but am quite certain >>> that iMPACT is OK with instruction register lengths down to 2 bits >>> (which is the minimum allowed by the standard). My cursory >>> examination of the Atmel data sheets indicates that the part has 2 >>> pins that control the test modes - a TST (which seems to enable some >>> manufacturing modes so it must always be low) and the JTAGSEL (which >>> seems to be temperamental in that a reset is required between >>> toggles). I'm wondering if the FPGA pins are connected to either of >>> these pins and perhaps interfering with the boundary-scan chain >>> during configuration? I'm suspicious of some interaction of that >>> sort, if not between the FPGA and those pins, perhaps some other ones >>> - or perhaps an interaction between the processor pins and PROG or >>> the FPGA mode pins during configuration. >>> >>> Idle thoughts... >>> >>> Glad you have a work-around. >>> >> yes I have a workaround that is ok so far, but for production test I need >> correct solution too. >> >> JTAGSEL is connected to PLD, everything was fine until I changed the >> JTAGSEL >> value by reprogramming the PLD, afer that impact just frozed while >> trying to reporgram the PLD. >> >> so no matter the the reason for the fail, there is some sort of bug >> with impact as any kind of >> wrong behaviour of the JTAG chain during programming should not cause >> impact to freeze. >> >> my guess about the 3 IR bits not supported was based on fact that as >> soon as reverted >> the ARM into ICE mode with longer IR register everything started to >> work again. the >> ARM has been unprogrammed all the time, only change to revert the >> chain useable >> was disconnecting JTAGSEL - as JTAGSEL is only latched on power up the >> connection >> to PLD can not change the scan chain config once powered. >> >> well FPGA PROG_B is also connected to the PLD, but it should not >> matter as the >> signal that made the difference was JTAGSEL on ARM, no matter the FPGA >> connections it should not prevent the PLD from being programmed - as long >> as ARM IR chain doesnt chain its length during runtime. I will >> investigate it >> a little more when the board is otherwise fully tested. >> >> Antti >> > > Hmm. Which PLD is involved here? I'm suspicious that iMPACT is not > actually frozen but just taking a really long time to fail. If it is a > 9500/XL/XV then these devices use polling to indicate when programming > (or erasure) is complete. The device responds with a status to iMPACT > to indicate success or failure. Some failure statuses mean keep trying > - just wait longer. The wait time increase can quickly increase to > minutes in certain failure situations. I am speculating that the PLD > mucks with JTAGSEL doing something horrible to the boundary-scan chain, > making the output look like the status that says "keep trying - just > wait longer" and then you end up with this apparent "freeze". Bad > behavior. Should fail more elegantly if that's what happening. That's > my theory, anyway. > >> >> >> >> >> >> >> >>Article: 96019
I am not yet done with my debugging yet, but thought would find out if anyone out has experimented with slave serial configuraiton of Spartan3. Here is the setup on my PCB board. The HSWAP_EN is tied to ground. The mode pins are floating. An Atmega128 running at 5V has mapped to it the configuration signal I/O of the FPGA. The PROG_B, INIT, CCLK, DIN. A series resistor(300ohm) is connected between the DIN (FPGA 3.3V)and Atmega128(5V). I can configure the FPGA from a JTAG port without changing the mode pins. I configure(via JTAG) the FPGA to run a continuous loop to blink LEDs. Then my Atmega drives the PROG_B signal low, which resets the FPGA. The INIT line is then checked and for some reason(using a Oscope) I have not been able to see the INIT line go low at all. After checking the INIT line, the atmega drives the CCLK low. The atmega128 reads one byte from the flash and then unpacks each byte and toggles the DIN signal according to the byte. The sequence for the 8 bits is as follows: CCLK_LO() toggle DIN(LSB) CCLK_HI() toggleDIN(LSB) CCLK_LO() toggle DIN(LSB+1) CCLK_HI() toggle_DIN(LSB+1) and so on. I have counter which keeps track of the bytes,which is 212393 bytes for a Spartan3XC3S400. After counter expires, I toggle the CCLK a few more time (as said in earlier discussions on this fourum). I am not sure why the DONE bit is not going high????? Any ideas?Article: 96020
I think you are taking the wrong approach. I'm sure you can get the C code running. But in reality if you have to implement sin/cos & sqrts, then the C code will be far from optimal, and you might need a vertex to do the job of a Spartan Simon "Pete Hudson" <pete.hudson@baesystems.com> wrote in message news:1138358605.349842.85640@z14g2000cwz.googlegroups.com... > I have been presented with a c program to implement on an fpga. > I am investigating the possible processes/tools I could employ rather > than a straight rewrite in VHDL. > > Current candidates are: > > Impulse C > Handel-C > Xilinx System Generator > > The algorithm is littered with sin cos sqrt & divides. So I expect that > I require some of the xilinx IP cores that come with my ISE tool. > (That's why XSG is getting a look in) > > Q. How do I implement this algorithm's cos functions (for example) in > Impulse C so that it is represented in the resultant HW? >Article: 96021
Hi Yeah had the same problem with that library. I dont think they have any interest in fixing it either. So I use lwip now. That had bugs too, Xilinx bugs, but they have sorted it out now. -- ---------------------------------------------- Posted with NewsLeecher v3.5 Beta 2 * Binary Usenet Leeching Made Easy * http://www.newsleecher.com/?usenet ----------------------------------------------Article: 96022
Hallo, Is it possible to connect a FSL peripheral to a XCL channel of Xilinx Multi-Channel Sdram Controller? I would read data from memory and send it out the fpga. -- MarcoArticle: 96023
Kolja Sulimma schrieb: > Why? An ethernet frame is hundreds of bits and you can still receive it > with an ISERDES. > Use a 1:6 serdes and continue to process your data stream in chunks of > 6-bit at a convenient rate of 80 MHz. You can add logic in the > FPGA-fabric that immediately converts the stream to 12-bits at 40MHz. > But probably you get a smaller circuit when you do all your signal > processing 6-bit-nibble serial at 80MHz. > This issue came up in this newsgroup a few times before. Somehow > everybody immediatly recognizes that a 16-bit entity can be split up > into two bytes of 8-bits. But as soon as the numbers change a little > apparently it becomes less obvious. That's not the problem. The thing is that the ADC sends out, along with the data, a fast clock and a 6x slower clock. If you run the ADC at 70MHz, it sends back a 420MHz clock and a 70MHz clock. The whole thing is designed so you use the 420MHz to clock some sort of deserializing-circuit and the 70MHz to clock out the parallel data and do your processing. So that's the "intended" way to handle this, and of course you'd first look for a way to do it with what you're provided with. Now, since one single ISERDES doesn't handle DDR, it would have to be run at 840MHz, plus I'd need to waste a DCM to double the clock (can they even get up to 840MHz?) I get from the ADC. No way. Alternatively, I could use two ISERDES in Master-/Slave-Mode (then they can handle DDR) to output two 6bit-nibbles, as you suggested. But to get these out, I'd have to have a 140MHz clock, which I don't have. Again, waste a DCM to generate it. And since I normally have 4 of those ADCs hooked up to one FPGA, that's 4 DCMs gone already, in addition to the 4 I need to do phase-shifting anyway. That's 8 total, which is probably every single one available in the devices I have available. Again, no way. The whole point of using the ISERDES in the first place is to save on DCMs, clock nets and hand-placed components, to make do with what is readily available. I still don't see where the ISERDES would make anything easier. cu, SeanArticle: 96024
"Neil Glenn Jacobson" <n.e.i.l.j.a.c.o.b.s.o.n@x.i.l.i.n.x.c.o.m> schrieb im Newsbeitrag news:drehdt$ngt8@cliff.xsj.xilinx.com... > The PLD pins float during programming. Depending on the CPLD, it is > typically pulled high, weakly, while the device is being programmed. You > might want to install a strong pull-up on the JTAGSEL to hold it high > during configuration and see if that helps things. If JTAGSEL floats low, > you will be hosed - it appears. > > Again, not knowing which Atmel device you are using you may also find this > instructive: > > http://www.atmel.com/dyn/products/faq_card.asp?faq_id=780 > Hi Neil, hmmm - the JTAGSEL is only captured at powerup later level changes (PLD pins floating) should not cause any change or trouble. also I would have expected JTAG problems in the case where ARM-ICE JTAG is in chain but it is the other way around, when ICE is in chain all works, when ARM boundary scan is in chain then the chain is scanneable, but impact fails really strange. I would be happy to leave the JTAGSEL=0 and ARM in ICE mode, but the manufacturer of the board wants to access boundary scan on all devices that support it, this includes the ARM and yes the PLD is XC9572XL, but complete freeze (or what seems as complete freeze) could still be prevented, ie the 'abort' button should be responsive also during the wait periods Antti
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