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
In article <4iak6qF2v1p3U1@individual.net>, Mike Treseler <mike_treseler@comcast.net> wrote: >Eric wrote: > >> But if anyone writes a book like this it will fly off the shelves! > >A few hundred copies would fly off the shelves. > >There's probably about 10,000 digital designers >in the US. Not all of those do hardware description >and not all of those write their own RTL. >Those are not numbers that would excite >a major publisher. >Writing and editing a book is two long years >of work, whatever the subject. In the software world if it took two years to write a book the content would be seriously outdated by the time the book came out. A lot of the publishers of software books (O'Reilly, The Pragmatic Programmers even APress now) are aiming for a six month cycle. In fact those publishers have now gotten the idea of selling pre-release titles as PDFs: you buy the pre-release PDF early for a reduced fee so you have access to the content and then later on when the final book comes out you get the paper version for an additional fee. That way your readers can access time-sensitive information early on. The other issue with hardware books like this is that the market is relatively small (I'm guessing that the ratio of software engineers to hardware engineers is at least 30:1). It could be a good opportunity to self publish where you publish not paper books but PDFs (this is happening on the software side). Then instead of having to pay $70 for a title because the audience is small, the author charges $20 for a pdf and gets to keep all of it instead of getting a small royalty from a publisher. If you manage to sell 1000 of them you've made $20K and that's generally a lot better than what you'd get from a publisher. One publisher (The Pragmatic Programmers) even publishes mini-books which are less than 100 pages (not paper, pdf only) which they sell for $8 to $10. It wouldn't be hard to write 100 pages in 2 to 3 months (part-time even). PhilArticle: 105376
MM schrieb: > "Antti" <Antti.Lukats@xilant.com> wrote in message > news:1153409257.506579.321890@i42g2000cwa.googlegroups.com... > > rsg schrieb: > > > > I guess Xilinx webmaster is on the vaccation again. There are two words > > I have for the Xilinx webmaster, unfortunatly not translateable: "na > > mylo!". > > Nu zachem tak uzh srazu... Seriously, I don't think it's a job for one > person, so maybe he/she is a little overwhelmed... > > /Mikhail ty prav, I sometimes overdrive my comments. I had just wasted 2 days with webpack download, and the website is somewhat broken most of the time. but you are right the 'poor webmaster' possible isnt the only reason that people do have frustration with Xilinx website. I realized myself that my commentary was too heavy and possible wrongly addressed - but solving the issues with xilinx website accessibility and faster update of latest info would not hurt anttiArticle: 105377
On 21 Jul 2006 04:42:09 GMT, ptkwt@aracnet.com (Phil Tomson) wrote: <Stuff snipped> > >The other issue with hardware books like this is that the market is >relatively small (I'm guessing that the ratio of software engineers to >hardware engineers is at least 30:1). It >could be a good opportunity to self publish where >you publish not paper books but PDFs (this is happening on the software side). >Then instead of having to pay $70 for a title because the audience is >small, the author charges $20 for a pdf and gets to keep all of it instead >of getting a small royalty from a publisher. If you manage to sell 1000 >of them you've made $20K and that's generally a lot better than what you'd >get from a publisher. One publisher (The Pragmatic Programmers) even >publishes mini-books which are less than 100 pages (not paper, pdf only) >which they sell for $8 to $10. It wouldn't be hard to write 100 pages in >2 to 3 months (part-time even). Self-publishing on actual, old-fashioned paper has become surprisingly affordable of late. Take a look at lulu.com or blurb.com and be amazed. Bob Perlman Cambrian Design Works http://www.cambriandesign.comArticle: 105378
wuyi316904@gmail.com wrote: > hi,friends: > I am a fresh man in IC design.How can I start my study in system > design?I need ur suggestions.Can u commend some book for me?How to > write the system specification？How to construct the system model?How > to verify in system level?What tool and language should I use？ > > And now,I use FPGA/CPLD to implement my design,I also want to > know some methods about static timing analyze of FPGA/CPLD. > Thanks a lot. > Generally an education is what you expect coming _out_ of school, not going _in_.* The biggest suggestion I can make? Lose the heavy text message accent. ur txtbks dnt do it, so why in heck should you? * Miles Vorkosigan, from Louis McMaster Bujold's "A Summer Campaign". -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 105379
Thanks we managed to do it ! Stéphane. "Jim Granville" <no.spam@designtools.co.nz> a écrit dans le message de news: 44bd552f$1@clear.net.nz... > sjulhes wrote: >> Hi all, >> >> I have a JED file for an old PAL device and I have to put this design in >> an EPLD. >> Is there a tool that can read the JED file and translate it to any usable >> language (vhdl, verilog or other ) ??? >> >> Have you any tip for this handling JED files ?? > > Some choices: > * Some device programmers will do this : eg PGM 16V8 as 16L8 etc > * Anachips WinPLACE will take old JEDs and create JEDs for their SPLDs > [but it seems to not create an EQN report, which would have been > sensible.. ] > * Search for JED2EQN, from Natsemi's ancient Opal sw > * reverse engineer of JEDs is not complex, but is a task best avoided... > > -jg >Article: 105380
i did it before ask but i didnt find anithing good and thanks for your great post motty wrote: > Doing an Internet search helps things sometimes. > > David wrote: > > hi > > i am new whit this technology. > > so anyone have or know about a good tutorial of fpga vhdl etc... > > i bougth the spartan-3E starter kit > > thanks > > > > DavidArticle: 105381
kayrock66@yahoo.com ha escrito: > The circuits look fine, my guess is that you made a clock that isn't > using the global routing and based on the luck of the draw one circuit > meets hold time and the other doesn't. If you are making a clock using > the general logic make sure you put onto a dedicated clock net before > use. That way it will meet hold time by architecture instead of luck. > > Jay > > oopere wrote: > > Quartus II is reporting a clock hold time violation in a circuit which > > may be described by the following diagram: > > > > -------- -------- > > d FF q--[logic]--d FF q > > -clk | -clk | > > | -------- | -------- > > | | > > --o------------------ > > > > I understand that the problem is that the input d of the second FF > > changes too early after the common clock edge. However, somewhere else > > in the same circuit I have the following > > > > -------- -------- > > d FF q-----------d FF q > > -clk | -clk | > > | -------- | -------- > > | | > > --o------------------ > > > > and quartus II does _not_ report any hold time violation here, and > > obviously enough, the situation is even worse. > > > > Something similar appears if I build a divide by 2: > > a) directly (inverted q to d) or > > b)using a 1 bit wide lpm_counter. > > In the first case, I get a hold time violation and everything is ok in > > the second case. > > > > Perhaps someone can provide some insight into the following questions: > > > > 1. Is something inherently wrong with the first schematic? I even > > thought it was always good idea to resynchronize signals in a similar > > way. > > > > 2. In case this approach is ok, why does quartus II report clock hold > > time problems? > > > > 3. If applicable, what should I tell the quartus II timing analyzer to > > get rid of this error? > > > > Thanks, > > Pere Thanks for your reply. Both parts of the circuit use the same clock signal. For this clock signal I have also tried to add an assignment of the type: "global signal" "global clock" "yes" with no success. (Before of this I only had: "auto global clock" "on" "yes" which I thought was sufficient). Is there any other way to "put onto a dedicated clock net" as you suggested? PereArticle: 105382
Rob ha escrito: > Also, look at the multi-cycle hold in the help section of Quartus. > > > "oopere" <oopere@netscape.net> wrote in message > news:1153408027.691966.40970@i3g2000cwc.googlegroups.com... > > Quartus II is reporting a clock hold time violation in a circuit which > > may be described by the following diagram: > > > > -------- -------- > > d FF q--[logic]--d FF q > > -clk | -clk | > > | -------- | -------- > > | | > > --o------------------ > > > > I understand that the problem is that the input d of the second FF > > changes too early after the common clock edge. However, somewhere else > > in the same circuit I have the following > > > > -------- -------- > > d FF q-----------d FF q > > -clk | -clk | > > | -------- | -------- > > | | > > --o------------------ > > > > and quartus II does _not_ report any hold time violation here, and > > obviously enough, the situation is even worse. > > > > Something similar appears if I build a divide by 2: > > a) directly (inverted q to d) or > > b)using a 1 bit wide lpm_counter. > > In the first case, I get a hold time violation and everything is ok in > > the second case. > > > > Perhaps someone can provide some insight into the following questions: > > > > 1. Is something inherently wrong with the first schematic? I even > > thought it was always good idea to resynchronize signals in a similar > > way. > > > > 2. In case this approach is ok, why does quartus II report clock hold > > time problems? > > > > 3. If applicable, what should I tell the quartus II timing analyzer to > > get rid of this error? > > > > Thanks, > > Pere > > Rob, Thnaks for the reply. However, as I understand it, multi-cycle hold assignments only would make sense if the processing took more than on clock cycle (correct me if I'm wrong). In this case, the hold time violation is because the processing is too _fast_ causing the input to FF2 change to fast after it's clock edge. PereArticle: 105383
Web page with block diagram and outline spec is now on website here http://www.enterpoint.co.uk/moelbryn/tarfessock1.html. John Adair Enterpoint Ltd. John Adair wrote: > We have mentioned Tarfessock1 before and now at the last point where we can > add features for the board. You know have the last chance to ask for things > you might want in this Cardbus format card so do ask. Currently the spec on > the card is as follows: > > Dual Spartan-3E (Device 1 notionallly fixed covering Cardbus interface etc), > Device2 programmable from Device1 or SPI prom. > Device 2 = XC3S1200 or XC3S1600 > 4 ch DAC > 8 ch A/D > O/P JTAG - looks like parallel port + cable3 for programming outside target > boards. Supported by Device1. > 1 serial RS232 interface outside world for MicroBlaze support etc. 1 > internal serial (TTL) also possible to Device2. > 4 ch RS485 serial controllable half duplex. > SDRAM + second SPI Flash on Device2 > Approx 70 5V tolerant I/O to outside world. > Switched 3.3V O/P to supported external modules that don't need to be > powered all the time (i.e. for running in the wild on laptop battery etc). > > We are using a 120 pin connector to support all these features and there > will be breakout board/s available to better pitches. > > We are currently still on schedule for a September launch. > > John Adair > Enterpoint Ltd. - Soon to be Home of Tarfessock1. The Spartan-3E Cardbus > Development Board. > http://www.enterpoint.co.ukArticle: 105384
We think this all going to fit but certainly will be very tight. I will know more in few days when placement is more complete. SDRAM is likely to be DDR2 as we are using that on a number of boards but still not fully decided. DDR2 needs 2 more power supplies and hence board space. We make decision when we see how placement works out. Fallback position is SDRAM. John Adair Enterpoint Ltd. Tommy Thorn wrote: > John Adair wrote: > > .... Currently the spec on the card is as follows: > > > > Dual Spartan-3E (Device 1 notionallly fixed covering Cardbus interface etc), > > Device2 programmable from Device1 or SPI prom. > > Device 2 = XC3S1200 or XC3S1600 > ..... > > SDRAM + second SPI Flash on Device2 > > All that fits on a cardbus card?? :-) > > What size, speed, and buswidth of the SDRAM? The ideal would be the > largest RLDRAM-II device possible, but failing that, as large and fast > as possible. > > Any price estimates yet? > > Regards, > TommyArticle: 105385
Bob Probably won't be as many as desireable but the option of using virual grounds using switched FPGA I/Os will be possible. I will also see if we can make any build options to hard ground what are I/O pins via solder bridge or 0201 resistor etc. Generally we could use a few I/O than we have available on the 120 way connector currently pencilled in but the next size up standard connector is 180 way and is a bit big physically for the card edge. Generally we are trying to an internal standard for what might be developed as future products beyond Tarfessock1. If we get a good response to this card it likely we will do a big brother version in Virtex-5 but that is only one of many projects competing for team time in Q4 and not guaranteed to happen as yet. John Adair Enterpoint Ltd. Bob Perlman wrote: > Hi - > > I don't know if anyone else has mentioned it, but please make sure you > have lots of grounds, well spread out, on the external module > connector(s). > > Bob Perlman > Cambrian Design Works > http://www.cambriandesign.com > > > On Thu, 20 Jul 2006 10:48:42 +0100, "John Adair" > <removethisthenleavejea@replacewithcompanyname.co.uk> wrote: > > >We have mentioned Tarfessock1 before and now at the last point where we can > >add features for the board. You know have the last chance to ask for things > >you might want in this Cardbus format card so do ask. Currently the spec on > >the card is as follows: > > > >Dual Spartan-3E (Device 1 notionallly fixed covering Cardbus interface etc), > >Device2 programmable from Device1 or SPI prom. > >Device 2 = XC3S1200 or XC3S1600 > >4 ch DAC > >8 ch A/D > >O/P JTAG - looks like parallel port + cable3 for programming outside target > >boards. Supported by Device1. > >1 serial RS232 interface outside world for MicroBlaze support etc. 1 > >internal serial (TTL) also possible to Device2. > >4 ch RS485 serial controllable half duplex. > >SDRAM + second SPI Flash on Device2 > >Approx 70 5V tolerant I/O to outside world. > >Switched 3.3V O/P to supported external modules that don't need to be > >powered all the time (i.e. for running in the wild on laptop battery etc). > > > >We are using a 120 pin connector to support all these features and there > >will be breakout board/s available to better pitches. > > > >We are currently still on schedule for a September launch. > > > >John Adair > >Enterpoint Ltd. - Soon to be Home of Tarfessock1. The Spartan-3E Cardbus > >Development Board. > >http://www.enterpoint.co.uk > >Article: 105386
Hi thanks for all the responses @alupin: The reset is driven by an externel jumper on the board. It seems to work. @antti: Do you mean the RDY_STATUS signal in the ddr2_8x4_idelay_ctrl module? Yes it goes high shortly after reset. @joseph: Ich double checked all pins, ok. I played with the reset. I observed the design a little bit more using chipscope getting the following results: Ras, Cas and ddr2_we toggle right after reset deassertion, i think this is the initialisation of the ddr2. I dont know whether the ddr2 behaves correct but the init sequence is completed after about 500 clock cycles. THe COMP_VALID signal never goes high and also the read enable signals for the write and address FIFOs stay zero all the time, so I guess the init sequence fails. Does anybody know how I could check whether the RAM behaves correctly? We have no external termination on the board. Do I have to configure ODT somehow? Icant find anything about ODT in the Mig however there is the RTT option. I cant find any information about this option I guess it is related to termination resistors? Should I choose 75 or 150 ohm RTT? heiner Joseph Samson schrieb: > Antti wrote: > > heinerlitz@gmx.de schrieb: > > > > > >>Hi, > >>I build a DDR2 controller using the Mig 1.5. > >> > >>In functional simulation everything works without problems (as > > > > > > check that the iodelay calibrate block get locked if not it will > > disable everything else > > > > Antti > > > > 1. Check the map report to make sure that all your IOs go to the pins > that you want. > > 2. I found that the controller doesn't start up correctly from power-on, > but it can be reset by driving the SYS_RESET_IN signal high, then low. > > 3. If you can look at the command signals (RAS, CAS, WE) going to the > SDRAM, you should be able to see the INIT commands. After init, the > controller issues many read commands and looks at the strobe signals to > calibrate the iodelay. This should be obvious from the scope if you can > look at a datastrobe or two. > > 4. After the iodelay is calibrated, the controller writes a pattern to > memory then tries to read it back. If you have a chipscope, look at > COMP_DONE. When it is high, the memory is ready to use. I took this > signal out to the top of the hierarchy and have it as a register bit > that my PPC can look at to see the health of the memory. > > 5. Consider fixing the FIFO16s, at least the ones that hold the memory > addresses. The ones that hold the write data are clocked by the MClk and > MClk90, so they may be OK. > > > --- > Joe Samson > Pixel VelocityArticle: 105387
heinerlitz@gmx.de wrote: > Hi thanks for all the responses > @joseph: Ich double checked all pins, ok. I played with the reset. I > observed the design a little bit more using chipscope getting the > following results: Ras, Cas and ddr2_we toggle right after reset > deassertion, i think this is the initialisation of the ddr2. I dont > know whether the ddr2 behaves correct but the init sequence is > completed after about 500 clock cycles. THe COMP_VALID signal never > goes high and also the read enable signals for the write and address > FIFOs stay zero all the time, so I guess the init sequence fails. > > > We have no external termination on the board. Do I have to configure > ODT somehow? Icant find anything about ODT in the Mig however there is > the RTT option. I cant find any information about this option I guess > it is related to termination resistors? Should I choose 75 or 150 ohm > RTT? I don't think that the lack of termination is causing this problem. I inadvertently had my Vtt turned off and was still able to read and write. In your original post, you said: > - The other signals on the PCB (or on chip using chipscope) especially > (ras, cas, we, cs) do not toggle at all. Is this still true - if you put a scope on the PCB signals,can you see the RAS CAS and WE forming the Load Mode command? If you can't see this, then you have to start by figuring out why you're not driving those signals (since you've said that you can see them toggling internally with ChipScope). If you're looking at RAS, CAS and WE with ChipScope, figure out the sequence of commands that MIG is sending to the RAMs. You can download a DDR2 datasheet from Micron; they have a table that gives the command nanes for the combinations of RAS,CAS and WE. You'll probably have to start looking at the state machine in the ddr2_controller module to figure out where you're hanging up and what conditions are stopping your progress. --- Joe Samson Pixel VelocityArticle: 105388
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message news:djb0c2d96k2f7tjv3tg9k09dri31bb1gtk@4ax.com... > > However... it seems to me that comp.lang.verilog/vhdl > and comp.arch.fpga represents a useful pool of > expertise. It's not part of *my* skill-set to do this, > but I wonder if someone could consider setting-up > a Wiki (freely-editable website) that could be used > as a readily accessible repository of this kind of > stuff? > > Any takers? > I think the infrastructure is already available. http://en.wikibooks.org/wiki/Wikibooks:Engineering_bookshelf or even more appropriately:- http://en.wikibooks.org/wiki/Programmable_Logic Cheers, Syms.Article: 105389
A couple of years ago we've done some Spartan II development with Xilinx ISE tools (V5.2.03i). Now we want to do a design with a Spartan III but our tools are out of date or have expired. We've tried the Webpack 8.1i on a 3GHz Prescott with 1GB of RAM and found it very slow. Hence my question: What is a good system setup for reasonable comfortable Spartan III development? What kind of PC do we need and which tools? We don't want to spend too much on tools since we do FPGA only occasionally, but if our engineer is spending most of his time waiting for his tools to finish a job we may be better of spending a bit more. Thanks, --DFArticle: 105390
In the Wallace & Gromit film "The Wrong Trousers", Gromit uses a book called "Electronics For Dogs" to help him convert the NASA technotrousers to remote controlled operation. Is this the kind of thing you had in mind? Cheers TWArticle: 105391
Hi ive got some news, the init and calibration process seems to be succesful as tap_sel_done, data_tap_select and init_memory signals toggle at the end of the calibration process. However the init_done signal which is driven by COMP_DONE is not asserted. As COMP_DONE is generated by the pattern compare module, it seems to me that the read out data is corrupted. Could this be right? Am I right with my conclusions? What to do know? thx, regards Heiner Joseph Samson schrieb: > heinerlitz@gmx.de wrote: > > Hi thanks for all the responses > > @joseph: Ich double checked all pins, ok. I played with the reset. I > > observed the design a little bit more using chipscope getting the > > following results: Ras, Cas and ddr2_we toggle right after reset > > deassertion, i think this is the initialisation of the ddr2. I dont > > know whether the ddr2 behaves correct but the init sequence is > > completed after about 500 clock cycles. THe COMP_VALID signal never > > goes high and also the read enable signals for the write and address > > FIFOs stay zero all the time, so I guess the init sequence fails. > > > > > > We have no external termination on the board. Do I have to configure > > ODT somehow? Icant find anything about ODT in the Mig however there is > > the RTT option. I cant find any information about this option I guess > > it is related to termination resistors? Should I choose 75 or 150 ohm > > RTT? > > I don't think that the lack of termination is causing this problem. I > inadvertently had my Vtt turned off and was still able to read and > write. In your original post, you said: > > - The other signals on the PCB (or on chip using chipscope) especially > > (ras, cas, we, cs) do not toggle at all. > > Is this still true - if you put a scope on the PCB signals,can you see > the RAS CAS and WE forming the Load Mode command? If you can't see this, > then you have to start by figuring out why you're not driving those > signals (since you've said that you can see them toggling internally > with ChipScope). > > If you're looking at RAS, CAS and WE with ChipScope, figure out the > sequence of commands that MIG is sending to the RAMs. You can download a > DDR2 datasheet from Micron; they have a table that gives the command > nanes for the combinations of RAS,CAS and WE. You'll probably have to > start looking at the state machine in the ddr2_controller module to > figure out where you're hanging up and what conditions are stopping your > progress. > > > --- > Joe Samson > Pixel VelocityArticle: 105392
hello, I would like to use the PLL with a clock frequency below 4 MHz. But when I use the MegaFunction under Quartus, it says me that the minimum input clock frequency is 15 MHz. Is there an alternative to do a clock multiplication ? I would like to clock multiply the input frequency. I know that to have lower frequency that the input, I can just do clock divider, but me I want clock multiplier !! Thanks. Best regardsArticle: 105393
Hi, I have posted on comp.dsp about this and got interesting answers. I have just discovered this group so I would like to know if some of you have something to add... I have designed a 26 order IIR filter (13 biquads) Someone proposed on comp.dsp to use direct form I saying that it's was not the best structure for optimising the FPGA "space", the easiest to design though. I know that biquads implementation are better to control problems that occurs with FPGA By the way, I think that, when I will have succeed in designing a efficient 2nd order cells on the FPGA, I will be able to do any order of filters. As I will know how much "space" a single cell takes, I will just need to connect these cells in cascade. Do you think that Direct-Form (or even tranposed) I 2nd order structures with a pipeline at 2*Freq is the best way to achieve such a design? My sample rate is 18 Mhz. Thanks for your help. NB : The post on comp.dsp was titled "FPGA"Article: 105394
Not enough grounds is a serious problem for good, high speed design. If there's a decent job done with differential routing for LVDS pairs (and LVDS voltage banks) then the demands on the grounds are lighter, allowing both a slow-speed, many I/O solution *and* a high-speed solution. The Spartan3E Starter kit had more than a dozen differential pairs but only about 4 pairs were "usable" because the others shared signals with LEDs or test headers that left huge stubs. If you did a good job with differential pairs, the speed might be pushed through the development connector. "John Adair" <g1@enterpoint.co.uk> wrote in message news:1153470659.303728.303030@75g2000cwc.googlegroups.com... > Bob > > Probably won't be as many as desireable but the option of using virual > grounds using switched FPGA I/Os will be possible. I will also see if > we can make any build options to hard ground what are I/O pins via > solder bridge or 0201 resistor etc. > > Generally we could use a few I/O than we have available on the 120 way > connector currently pencilled in but the next size up standard > connector is 180 way and is a bit big physically for the card edge. > Generally we are trying to an internal standard for what might be > developed as future products beyond Tarfessock1. > > If we get a good response to this card it likely we will do a big > brother version in Virtex-5 but that is only one of many projects > competing for team time in Q4 and not guaranteed to happen as yet. > > John Adair > Enterpoint Ltd. > > Bob Perlman wrote: >> Hi - >> >> I don't know if anyone else has mentioned it, but please make sure you >> have lots of grounds, well spread out, on the external module >> connector(s). >> >> Bob Perlman >> Cambrian Design Works >> http://www.cambriandesign.com >> >> >> On Thu, 20 Jul 2006 10:48:42 +0100, "John Adair" >> <removethisthenleavejea@replacewithcompanyname.co.uk> wrote: >> >> >We have mentioned Tarfessock1 before and now at the last point where we >> >can >> >add features for the board. You know have the last chance to ask for >> >things >> >you might want in this Cardbus format card so do ask. Currently the spec >> >on >> >the card is as follows: >> > >> >Dual Spartan-3E (Device 1 notionallly fixed covering Cardbus interface >> >etc), >> >Device2 programmable from Device1 or SPI prom. >> >Device 2 = XC3S1200 or XC3S1600 >> >4 ch DAC >> >8 ch A/D >> >O/P JTAG - looks like parallel port + cable3 for programming outside >> >target >> >boards. Supported by Device1. >> >1 serial RS232 interface outside world for MicroBlaze support etc. 1 >> >internal serial (TTL) also possible to Device2. >> >4 ch RS485 serial controllable half duplex. >> >SDRAM + second SPI Flash on Device2 >> >Approx 70 5V tolerant I/O to outside world. >> >Switched 3.3V O/P to supported external modules that don't need to be >> >powered all the time (i.e. for running in the wild on laptop battery >> >etc). >> > >> >We are using a 120 pin connector to support all these features and there >> >will be breakout board/s available to better pitches. >> > >> >We are currently still on schedule for a September launch. >> > >> >John Adair >> >Enterpoint Ltd. - Soon to be Home of Tarfessock1. The Spartan-3E Cardbus >> >Development Board. >> >http://www.enterpoint.co.uk >> > >Article: 105395
EEngineer wrote:
> I have changed the order:
>
> Device #0 was xcf32p
> Device #1 xc4vsx35
> Device #2 xc95144lx
>
> Assigned the configuration bit file again to the xc4vsx35 device,
> generated ACE, put it on CF, again could not configure the board.
>
I just went ahead and generated a new ML402 ACE file using 8.1i and
copy the files to the CF card with no issue or doing anything outside
of the flow (such as SVF edits that you have been mentioning).
Try the following.
1) Start over with a new iMPACT System ACE project
2) Call the "Collection" name "my_ml402"
3) Only create one revision (rev0)
4) Set up the device chain as above XCF32P -> XC4VSX35 -> XC95144XL
5) Assign your 4VSX35 BIT file to the XC4VSX35 device
6) Generate the System ACE file with no other edits
7) Remove all of the files from your CF card
8) Copy just the single ACE that you just generated to the CF card
9) Insert the CF card in the ML402
10) Verify that SW12 is set to the SYSACE position
If this works then you have a good ACE file. If it doesn't work go
back and double check that you really have the correct chain defined
and that your bitstream is targeting a SX35 device and that you generate
the BIT file with the startupclk = jtagclk setting.
If you can't get a CF card with just an ACE file to work then you
probably have a mal-formated CF Card see this answer record to reformat
the card: http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=14456
Now that the ACE file is known to be good. You either have an address
switch setting issue or you copied the files incorrect to the CF card.
1) Remove all of the files from the CF card again
2) Copy the xilinx.sys and the "my_ml402" collection directory that you
generated earlier to the blank CF card.
3) Verify that the CFG ADDR switches 1, 2 & 3 are in the OFF state for
an address of 000
4) Insert the CF Card in the ML402
5) The ACE file should now load
Ed McGettigan
--
Xilinx Inc.
Article: 105396Hi there, has anyone ever tried to implement the XMatch-Pro lossless data compression algorithm on an FPGA and finally got it running? I ran into some problems I would like to discuss with someone who made a similar experience. Thanks in advance and best regards GeroArticle: 105397
Eric wrote: >> Is there some hardware RTL book like "Code Complete" by Steve >> McConnell? It's not exactly the same but "The Pentium Chronicles" by Robert Colwell is worth looking at. --Jon-Article: 105398
heinerlitz@gmx.de wrote: > Hi ive got some news, > > the init and calibration process seems to be succesful as tap_sel_done, > data_tap_select and init_memory signals toggle at the end of the > calibration process. > > However the init_done signal which is driven by COMP_DONE is not > asserted. As COMP_DONE is generated by the pattern compare module, it > seems to me that the read out data is corrupted. > > Could this be right? > Am I right with my conclusions? > What to do now? I'm assuming that this is a board of your own design, and not a prototyping board you bought off the shelf, because my first guess would be that there is either a mis-wiring problem (my board had the differential clock signals miswired + to -, even though we checked the schematic about a hundred times) or a signal integrity problem (like those missing terminators). You can try turning on ODT. You can either change the parameters_0.v file, or regenerate the design from CoreGen, clicking on the 'Set Mode Register" button and setting RTT to 75 ohms. There are two lines of attack: 1. Is the command and address correct? 2. Is the data correct? There are indirect ways to see if the commands are correct. Earlier, I said that part of the calibration is to issue read commands and calibrate the idelay by examining the datastrobes. If you are getting through that phase and you see datastrobes being generated, then the commands (RAS, CAS, WE, CKE, CS) are probably OK, or at least I'd look elsewhere. It's hard to tell if the address bus is OK without using a scope on the RAM. You can use ChipScope to see what the data looks like coming from the RAM, but be sure that you aren't accidentally connecting to signals that go to the IOB. The address and command signals go go IOB flipflops, but chipscope will happily move them out of the IOB so you can look at them, and as a bonus, you'll get lots or routing delay to confues the issues. If this is your own design, did you pay attention to the routing delays? My first design spec'd that signals had to be length matched to 200ps. In my second design, I spec'd 20ps. You could have everything correct, but the difference in path length could prevent the calibration circuit from aligning all the bits. --- Joe Samson Pixel VelocityArticle: 105399
I just found out how much the liscense for the altera core costs. Considering that production quantity will be relatively low, I would like to avoid using it if this is possible / practicle. Does the opencore one do bus mastering well enough to acheive the kind of tranfer rates I'm hoping for? Mark McDougall wrote: > What type of transfers are you looking at? Will it be PIO (single > byte/word/dword) transfers? Initiated by the PC? Or DMA, initiated by > the card? Is the data isochronous 27MB/s? Or can it be buffered and > transferred periodically in large chunks? It's an I/O interface that will be constantly receiving and transmitting something at 270 Mbps both directions using 8B/10B encoding. Which means potentially, we could want the card to transmit and receive 27 MB/s. However, in this particular application, rate of the real data will be closer to just 2MB/s. If there's a latency due to buffering & block tranfers, it's probably not a concern as long I can have large enough FIFOs on the FPGA that they never become empty while I'm filling the PC side buffer. The whole reason for this interface is to modify the input data stream and send it back out and the delay caused by CPU time is probably going to be considerably more -- although i'm not sure how much processing it will take because our customers are writing the software that does it and I have no direct way to contanct their developers.
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