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
Hi, dears:
I am heard that ISE is coded in Java. So it is very flexible when
migeration but is very slow. Is it true?
Article: 107351"Peter Wallace" <pcw@karpy.com> schrieb im Newsbeitrag news:pan.2006.08.26.16.39.34.985268.62399@karpy.com... > On Fri, 25 Aug 2006 12:41:38 -0700, Martin E. wrote: > >> I am looking for a way to read/write to a SATA drive from an FPGA. I've >> looked around. Nothing seems to fit the bill. Any ideas worth >> considering? >> >> Thanks, >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin >> >> To send private email: >> email = x@y.com >> where: >> x = "martineu" >> y = "pacbell.net" > > Not ideal pin count wise but how about a SATA-PATA bridge? > > We're using the JMicron chip, its inexpensive and goes both ways (host & > device) > > Peter Wallace thats almost the only possible solution and also the most cost effective as the SATA PHY+FPGA resource cost is higher then SATA-PATA IC cost AnttiArticle: 107352
<fpga_toys@yahoo.com> schrieb im Newsbeitrag news:1156638163.927585.251260@h48g2000cwc.googlegroups.com... > > Antti wrote: >> ML300 and digilent XUP V2Pro both have SATA connectors on >> them but can not actually be used for SATA as of compliance issues. >> (OOB and CDR lock range mainly) > > As a new owner of XUP V2Pro board, my comment is that Xilinx screwed up > royally by not joining the standards process BEFORE shipping a SATA > based product or design. I purchased the board simply BECAUSE it had > these interfaces. > > There are certain expectations that systems vendors actively take part > in industry standards if they are going to ship and support products > based on those standards. I've spent years of my life supporting > standards processes ... they are the most valuable customer asset a > systems company can invest in to protect both their products, their > customers products, and a safe product migration path over time. > Hi John, well I was in about the same situation as you, namly I recommended the purchase of ML300 (4695 USD !!) for an project, and I assumed that the SATA can be use don that board. Well Xilinx response was "Sure we thest the SATA on ML300! We use the BERT test application and loopback cable!" - you can imagine I wasnt very happy with such a response. At that time when that purchasing decison was made (base on my recommendatio) Xilinx MGT documentation listed SATA as on of the supported protocols. The updated MGT docs do not include SATA anymore. good god, I just checked the ML300 latest documentation and it still lists: "The ML300 provides for operation as a Serial ATA host or device." This is of course not true. Ok it must be that the ML300 docs have not been updated. Now to the XUP V2Pro board, first of all this board is designed made by digilent, so whatever is screwed up as you say with this board then its done by digilent, and not Xilinx. With the XUP board the SATA is a little better than with ML300 as the OOB fixup is added to the XUP (its missing on ML300) see page 29 of the XUP board schematic. The OOB can be done without the FET solution too when rx and tx are used from different MGT (not possible on ML300) I have tested that on Memec VP20 board where I did succesfull got past the OOB handshaking and was seeing the inband signalling from the Silicon Image SATA chip. So you should be also able to get SATA working on XUP. There isnt much ready IP for that, thats another question. And if you are considering an commercial product that has to pass __full__ compliance then I see no alternatives as using a external SATA-PATA bridge, it save you both development time and actual self cost of the product as well (relative cost of the SATA IP in terms of % of the FPGA is hihger than the SATA-PATA IC). And again, you can not blaime Xilinx in everything, sure it would be nice to use MGTs for SATA, and a free SATA IP core would be nice too, but - if you really read Xilinx documentation - they are no longer claiming MGTs to handle SATA, so if you missed that, you cant legally say anyhing. Just bad luck for you. AnttiArticle: 107353
On Sat, 26 Aug 2006 18:13:54 -0700, Austin Lesea <austin@xilinx.com> wrote: >jeff, > >I guess I'd be shocked, too. >We have been criticized, and properly so, for our sins and omissions of >the past. If anything, Xilinx does listen, and does place procedures >which are intended to prevent the kinds of problems we may have had in >the past. You may at least take some pride for your calling things to >our attention, as we do listen, and we do recognize that anything that >we can do better at, we should do better at. I hope you have also been complimented on the things you have done right, when they have been right... Such as - for exactly this sort of eventuality - the online store. Any chance of SMALL quantities of selected parts re-appearing there? - BrianArticle: 107354
"PLD Hacker" <pldhacker@tom.com> schrieb im Newsbeitrag news:ecrnvr$8n6$1@news.cn99.com... > Hi, dears: > I am heard that ISE is coded in Java. So it is very flexible when > migeration but is very slow. Is it true? > no it is not true. Java is used by 1) coregen 2) chipscope 3) planahead ? 4) EDK SDK (eclipse) maybe some other parts o ISE/EDK but not for the main GUI or tools AnttiArticle: 107355
PeteS schrieb: > Nico Coesel wrote: > > "PeteS" <PeterSmith1954@googlemail.com> wrote: > > > > >Jim Granville wrote: > > >> Austin Lesea wrote: > > >> > Martin, > > >> > > > >> > No, and No. Sorry, even V5 does not have the frequency tracking agility > > >> > to track the SATA spread spectrum clock. And because of that, we have > > >> > no IP for it, either. > > >> > > > >> > The ASSP vendors are very protective about their business: they > > >> > continue to make their little applications as tough to do as possible, > > >> > to keep out the 'big bad FPGA vendors' who seem to be eating up all > > >> > their businesses. (Hey, we are just trying to make our customers happy!) > > >> > > > >> > Too bad: when an industry is spending time being defensive, they have > > >> > already lost - any time spent not innovating means you are doomed to > > >> > failure. > > >> > > >> That probably depends on where you are standing. > > >> > > >> Could be, that the FPGA sector needs to innovate, and include > > >> sufficent agility to track a SATA spread spectrum clock ? > > >> > > >> Sounds more an issue of who decides the market is large enough to > > >> bother with, than any perceived fpga-vs-assp battles ? > > >> > > >> -jg > > > > > >I'll second this with an added comment: Spread spectrum clocks are an > > >absolute must in some areas, and very desirable in others; I would > > >*love* to use a spread spectrum clock in my newest design because it > > >does not have a metal enclosure and EMI/EMC is a major issue. > > >When you make FPGAs (or ASICs or any other chip for that matter) for a > > >living but not shipping board and enclosure level products it's easy to > > >forget 'little details' like this (regulatory compliance) that systems > > >and board designers live with day in and day out. > > > > > >Spread spectrum obviously alleviates the problem significantly (in some > > >very subtle ways too). A lot of vendors offer the ability to track a > > >spread spectrum clock; why not FPGA vendors too? > > > > You can as long as you don't use the DCM (or anything like it) and > > route the fpga for the highest allowed clock frequency. If you use an > > external device to create your clocks and feed them into the fpga, > > there is no reason why an fpga won't work with spectrum spread clocks. > > > > -- > > Reply to nico@nctdevpuntnl (punt=.) > > Bedrijven en winkels vindt U op www.adresboekje.nl > > My point is there is nothing I am using (or generating) in the design > that would suffer from spread spectrum (indeed, my design would benefit > higely) and I would love to generate all system clocks except a > processor from a spread spectrum master. That implies using the DCM (or > it's equivalent). > > A spread spectrum oscillator can be modelled as a device with > (introduced) jitter, and are quite well documented [if they aren't, I > don't use them]. I am astounded (in a way) that a DCM can't handle the > (relatively minor) deviation of a master clock to generate new ones > with the same percentage variances. > > If I have to use a PLL (which can be tuned to track such things), it > would mean either changing the device to a 'well known competitor' or > adding hardware (which adds power consumption I can not afford). > > Cheers > > PeteS Pete, 1) DCMs are not used for SATA clock at all, the MGT should be feed with 75MHz reference clock and the SATA data rate clock is recovered in the CDR inside the MGT. So any issues DCM may have are ir-relevant in the regards of SATA 2) the serdes PLL from an wellknown competitor doesn make that serdes more SATA compliant ASFAIK, Stratix-IIGX is not listing SATA as supported standard. LatticeSC is no listing SATA either. Info about Stratix-III and LatticeXP2 is not available yet. So there just isnt any FPGA silicon devices currently available at all fully confirming to SATA. If you use extenal SATA PHY, then the choice of FPGA is ir-relevant, any decent FPGA should be handle the SATA (after PHY layer) AnttiArticle: 107356
Hi u guys, I've decided to go with the different port width approach. Thanks alot for your answers. Mordeahy.Article: 107357
OK! Got it! thank you very much! "Antti Lukats" <antti@openchip.org> 写入消息新闻:ecru1v$kio$1@online.de... > "PLD Hacker" <pldhacker@tom.com> schrieb im Newsbeitrag > news:ecrnvr$8n6$1@news.cn99.com... >> Hi, dears: >> I am heard that ISE is coded in Java. So it is very flexible when >> migeration but is very slow. Is it true? >> > no it is not true. > > Java is used by > 1) coregen > 2) chipscope > 3) planahead ? > 4) EDK SDK (eclipse) > maybe some other parts o ISE/EDK > > but not for the main GUI or tools > > Antti > >Article: 107358
well, i'm guessing that there might be a multi-source in a concurrent assignment in your code... Error messages are normal.. if there are errors in your code ;-) See if you can find the error with your signal called 'integers' post some code if you get stuck... (if that's your signal name it's not a terribly nice btw) Ben "Marco" <marco@marylon.com> wrote in message news:1156511673.712837.195050@74g2000cwt.googlegroups.com... > Hi, > > anyone ever had something like this: > "ERROR:Xst:800 - "C:/MyFolder/control_unit_top.vhd" line 317: > Multi-source on Integers in Concurrent Assignment."? > It refers to a process line: > "control_make_reply: process(ctrl_top_clock)" > I'll provide further details if needed, but for this first post I was > just wondering if someone ever saw it working with ISE7.1 > > Thanks, > Marco >Article: 107359
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag news:44EF5DD5.5040502@xilinx.com... > Martin, > > SATA worked, but not when it used the spread spectrum clocking. There > was also some out of band signaling issues, where you needed a > transistor and a couple of resistors. > > So, it could be a point solution for a known drive that did not have > spread spectrum, but it was not able to deal with the the broad spectrum > of SATA product. > > Austin > Hi Austin, there is still a possibility to get V4FX or V5xxT MGTs to work with SATA gen 1 - the RX and TX MGTs are configured with 4 to 1 datawidht ratio and same ref clock, the RX is configured as full bypass with clock permanently disabled (V4 MGT new feature) . Those the RX would be running at at 6GBit/s, the RX CDR and PCS functions would have to be implemented in FPGA fabric. Not an easy task but doable. AnttiArticle: 107360
Peter, Double success! With your help, I solved both of my problems. First, I was able to run my program with xmd using the following commands: connect ppc hw -cable type xilinx_platformusb -debugdevice icachestartadr 0xffff0000 dcachestartadr 0xffff8000 xwreg 0 dbcr0 0x30000000 xwreg 0 msr 0x40000 xwreg 0 msr 0 dow vp30_ctrl.elf con Now I was confident that my bit file and my elf files were valid, and I was one step closer to making everything work with SystemAce. I then added the missing cache addresses in my xmd commands for SystemAce (thanks for pointing that out!). I made another ace file with the modified script and it worked on the first time! For the record, here are some hints about UltraController II + SystemAce that I learned along the way: - You need to use genace.tcl that comes with the reference design, NOT the genace.tcl from EDK. - You do not need to use genace_uc2.sh, it is simply a wrapper for genace.tcl, it is not required. - Do NOT use the file uc2.ngc from the reference design (actually, delete it to make sure). Instead, use the file uc2.vhd from the /hdl folder. Using uc2.ngc in my case created an invalid bit file which resulted in a "Programming failed" in impact. - Here's a valid set of commands to generate an ace file. These commands can be put in a your_options.opt file and xmd can be called like this: xmd -tcl genace.tcl -opt your_options So here's the your_options.opt file (for the Avnet V2Pro Eval Board): -jprog -target ppc_hw -hw your_hardware.bit -elf your_software.elf -ace final_system.ace -board user -configdevice devicenr 1 idcode 0x05026093 irlength 8 partname XC18V04 -configdevice devicenr 2 idcode 0x05026093 irlength 8 partname XC18V04 -configdevice devicenr 3 idcode 0x0124a093 irlength 10 partname XC2VP7 -debugdevice devicenr 3 cpunr 1 icachestartadr 0xffff0000 dcachestartadr 0xffff8000 My greatest thanks Peter, especially since you helped me over the weekend! It was really nice to get help from someone knowledgeable. Thank you also to the others who responded to this thread (Mikhail, Antti). You convinced me to give a try to the "normal" flow, and I actually did start on this path. I'll revert to the UC2 for the time being but eventually migrate to the full-blown PPC if needed. PatrickArticle: 107361
Antti Lukats schrieb: > there is still a possibility to get V4FX or V5xxT MGTs to work with SATA gen > 1 - the RX and TX MGTs are configured with 4 to 1 datawidht ratio and same > ref clock, the RX is configured as full bypass with clock permanently > disabled (V4 MGT new feature) . Those the RX would be running at at 6GBit/s, > the RX CDR and PCS functions would have to be implemented in FPGA fabric. > Not an easy task but doable. Hmm, maybe. But probably with a hell of logic ressources. If it would be easy, Xilinx would have implemented it into the hard macro, right? But I guess the world (of SATA) is not that bad. AFAIK the spread sprectrum clocking in OPTIONAL and is activated by a register in the drive. So the FPGA application can run fine without spread spectrum option (ok, a metal case will help to fight EMC problems) No big deal at all for me. Comming generations of FPGAs will support spread spectrum stuff. Regards FalkArticle: 107362
Peter, Typically, people use a two current technique, which removes process variation from the equation (lierally). The National, Linear, etc. chips measure voltage drop at I1, and then at I2, and then solve for temperature. There are two numbers you need to know: the ideality factor, and the series resistance. With those two numbers, you can then solve for temperature using the two current technique (by hand, if you like, as the ICs will not like being connected as you will be doing if you use the IOB intrinsci diode). Just look up the IC app notes for these temperature sensors, like: http://pdfserv.maxim-ic.com/en/an/AN3641.pdf#search=%22diode%20temperature%20sensor%20IC%22 (Maxim, in this case) In the V4 data sheet we state the two constants, as some ICs allow you to program these constants into them. AustinArticle: 107363
More useful link, http://cache.national.com/ds/LM/LM95231.pdf see page 17 AustinArticle: 107364
Brian, Peter is still tilting at that windmill (the on line store). I am cheering him on. Perhaps Peter can tell us how the on line store is progressing when he bets back from Europe. AustinArticle: 107365
I'm designing a Cyclone device and am having problems with one pin. I want to use the configuration pin ASDO as an I/O pin after my device finishes active serial configuration. I assigned my I/O to that pin but the fitter barks at me that it "Can't place node ~ASDO~ in location 37 because location already occupied by Q[0]" I went to Assignments... Device... Device & Pin Options... Dual-Purpose Pins, but the setting for ASDO is greyed out. How do I tell Quartus to let me use that pin as an I/O pin after AS configuration? Thanks, -NevoArticle: 107366
>> BTW: As I'm also academic I should/have to publish papers. SimpCon >> is on my list for months to be published - and now it seems to be >> the right time. I will write a draft of the paper in the next few >> days. If you are interested I'll post a link to it in this thread >> and your comments are very welcome. >> > OK. > I've uploaded the first draft of the paper: http://www.jopdesign.com/doc/simpcon_date.pdf It's still very similar to the SimpCon definition at opencores.org. Comments are very welcome. To KJ and Tommy: I've added you both in the Acknowledgments. I hope this is ok with you ;-) MartinArticle: 107367
I'd first like to commend Antti for his professionalism this morning in making civil and respectful replies in this forum. It's very difficult to be forced to respond in kind, and dress down such a wonderful resource in this forum, simply because he got sucked into a pecking frenzy setup by Austin and Peter lack of civility in this forum. Antti Lukats wrote: > Now to the XUP V2Pro board, first of all this board is designed made by > digilent, so whatever is screwed up as you say with this board then its done > by digilent, and not Xilinx. With the XUP board the SATA is a little better > than with ML300 as the OOB fixup is added to the XUP (its missing on ML300) > see page 29 of the XUP board schematic. The XUP board AFAIK is a Xilinx board resold by Digilent, and probably other sources. The board does not have the Digilent name anywhere on it, and the documentation is all Xilinx documentation. I looked at all the available boards before making the choice to use this system to prototype this embedded controller contract. > So you should be also able to get SATA working on XUP. There isnt much ready > IP for that, thats another question. And if you are considering an > commercial product that has to pass __full__ compliance then I see no > alternatives as using a external SATA-PATA bridge, it save you both > development time and actual self cost of the product as well (relative cost > of the SATA IP in terms of % of the FPGA is hihger than the SATA-PATA IC). The terms for the RFQ require full SATA compatability and compliance, which Xilinx has clearly failed to provide at this point. Given Austin's whining, it's pretty clear Xilinx is offering a bait and switch, with no intent of joining SATA-IO and offering a fully certifiable solution for Xilinx designers. > And again, you can not blaime Xilinx in everything, sure it would be nice to > use MGTs for SATA, and a free SATA IP core would be nice too, but - if you > really read Xilinx documentation - they are no longer claiming MGTs to > handle SATA, so if you missed that, you cant legally say anyhing. Just bad > luck for you. Excuse me .... why not blame Xilinx for the gross missrepresentations in the XUP product? It's clearly their product ... their design (Xilinx Research Labs) and their missleading advertising and documentation. And it's clearly their failure to join SATA-IO if they are offering a SATA solution for Xilinx FPGA designers, and to make sure the documentation for these boards is complete, including the compliance failures.Article: 107368
fpga_toys@yahoo.com wrote: > and to make sure the documentation > for these boards is complete, including the compliance failures. This is probably the most unethical part of Xilinx, ommissions which suck you and I into wasting valuable time and resources on a completely unusable design strategy. How do you trust anything, when your supplier has a track record of omissions ... and failure to disclose problem areas .... from valid (meets ISE timing reports) designs failing on parts, to lack of SATA compliance of reference designs?? And then compound that with Austin's and Peter's overt denial of problems in this forum, till cornered. "Lost, Totally" (as Austin ridicules) .... is Xilinx, Austin, and Peter.Article: 107369
Martin E. wrote: > I am looking for a way to read/write to a SATA drive from an FPGA. I've > looked around. Nothing seems to fit the bill. Any ideas worth considering? Hi Martin ... would like to share an email reply I got from someone who seems to be a bit gunshy about publicly suggesting Altera: "there is not much for Altera to listen too, SATA defenetly works on Altera when using SAPIS PHY. in the regards of making S-3GX serdes directly SATA compliant, sure Altera does it if it technically reasonable. There is no need for Altera to license something. Its just the serdes-pll block characteriscitcs, either they are flexible enough to be use in SATA compliant mode or not." Something I will certainly be looking into this week. It would be nice if the Altera folks would confirm this specifically, and offer some public confirmation as there seems to be several of us with potential near term design wins for Altera if true.Article: 107370
"Falk Brunner" <Falk.Brunner@gmx.de> schrieb im Newsbeitrag news:4ldt6eF1f1g8U1@individual.net... > Antti Lukats schrieb: > >> there is still a possibility to get V4FX or V5xxT MGTs to work with SATA >> gen 1 - the RX and TX MGTs are configured with 4 to 1 datawidht ratio and >> same ref clock, the RX is configured as full bypass with clock >> permanently disabled (V4 MGT new feature) . Those the RX would be running >> at at 6GBit/s, the RX CDR and PCS functions would have to be implemented >> in FPGA fabric. Not an easy task but doable. > > Hmm, maybe. But probably with a hell of logic ressources. If it would be > easy, Xilinx would have implemented it into the hard macro, right? > But I guess the world (of SATA) is not that bad. AFAIK the spread > sprectrum clocking in OPTIONAL and is activated by a register in the > drive. So the FPGA application can run fine without spread spectrum option > (ok, a metal case will help to fight EMC problems) > No big deal at all for me. > Comming generations of FPGAs will support spread spectrum stuff. > > Regards > Falk Hi Falk, hmm.. I havent checked that, I actually also assumed that spread spectrum is optional, but I did not check on the spec. So I commented biased on Xilinx assumptions that the spread spectrum clock makes some drivers not useable. Last time I worked with Xilinx SATA I wasnt as far as about to worry about spread spectrum. V2Pro was clearly out SATA of spec because CDR hard lock range as there was no cure to that. This is clearly fixed in V4FX - well maybe we should wait up SEG's comments on this. AnttiArticle: 107371
fpga_toys@yahoo.com schrieb: > Martin E. wrote: > > I am looking for a way to read/write to a SATA drive from an FPGA. I've > > looked around. Nothing seems to fit the bill. Any ideas worth considering? > > Hi Martin ... would like to share an email reply I got from someone who > seems to be a bit gunshy about publicly suggesting Altera: > > "there is not much for Altera to listen too, SATA defenetly works on > Altera when using SAPIS PHY. in the regards of making S-3GX serdes > directly SATA compliant, sure Altera does it if it technically > reasonable. There is no need for Altera to license something. Its just > the serdes-pll block characteriscitcs, either they are flexible enough > to be use in SATA compliant mode or not." > > Something I will certainly be looking into this week. It would be nice > if the Altera folks would confirm this specifically, and offer some > public confirmation as there seems to be several of us with potential > near term design wins for Altera if true. gosh - there is an overview document at Altera website with Nuvation SATA IP core working in Altera FPGA - uses external SAPIS compliant PHY. http://www.nuvation.com/ipcores/sataa.html above is the nuvation link AnttiArticle: 107372
Hi, I am learning Modelsim 6.1e XE coming from ISE webpack. In its tutorial lesson 4, it gives an example about creating resource library. After doing that, I modified the source of that resource library. I found that my simulation did not reflect my changes even I refreshed that resource library. The only way is to totally delete that library and recreat it. Do you have method to update a user defined library? Thank you.Article: 107373
To the subject at hand: placing additional caps across existing caps does not reduce the noise (unless the dominant cause is lack of adequate capacitance). The reason why the noise is bad is that the L (as in Ldi/dt) is most likely the largest, and most dominant factor, in the form of the via and traces to the bypass capacitor. Many times people have placed additional caps on top of the the existing caps and wondered why the noise is not reduced: well, you did not change the L in the equation, did you. So why did you expect V to change? You may have moved the resonant frequency (more often not), but often people make the mistake of assuming that a 0.1uF requires a 0.01uF and a 0.001uF in parallel. You can see that if the series L is dominant, you haven't even moved the frequency by more than a few percent by the small amount of additional capacitance. Unfortunately, once the via and trace L is large, there is no way to make the noise less, withpout making a whole new pcb (re-layout). More that once we have had to inform a customer that there is "no hope" for their pcb because the series L in their layout is dominant, and there is no way to reduce it. And, we have then helped them re-layout their pcb and making their system work just fine (as, if you know what you are doing, this is not a hard problem to solve). Mark Alexander's power distribution application note represents the latest state of our power distribution sysem "knowledge." As we learn more, we will certainly update the applications note. Again, my apologies to the group for a new thread, on an old subject. AustinArticle: 107374
I'd like to check timing of my cicrcuit.. I have chosen post-route
simulation... does it show how it works in real device?
I use clock from DCM.. there is BUFG on output.. BUFG makes good routing,
correct? I used it one more time
In DCM I generate clock for memory.. How should I tranport this signal?
>From DCM by new BUFG:(?)
BUFG_INST : BUFG
port map (I=>DCM_OUTPUT_CLOCK,
O=>CLK_FOR_MEMORY);
I think better is giving clock from component which gives data and signal
controls because path for clock and signal controls will be the same.
DCM_OUTPUT_CLOCK = > Component_DRIVER => BUFG => CLK_FOR_MEMORY2
If I make both, CLK_FOR_MEMORY is different than CLK_FOR_MEMORY2.
And the best is: signal sensitived of DCM_OUTPUT_CLOCK, is earler on output
than CLK_FOR_MEMORY2 and CLK_FOR_MEMORY. (If i use BUFG).
I do not know if BUFG is necessary... I saw that BUFG delays my clock and I
am happy because memory wants to get controls signal before rising clock.
If someone can tell me anything, I will be gratefull :-)
Thanks,
zlotawy
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