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
Thanks, you are right. The example from the handbood is wrong. Alan Nishioka a =E9crit : > fl wrote: > > Info: Selected device EP1C12Q240C6 for design "filtref" > > Info: Fitter is performing a Standard Fit compilation using maximum > > Fitter effort to optimize design performance > > Error: Can't place node "clk" -- illegal location assignment PIN_G1 > > Error: Can't fit design in device > > Error: Quartus II Fitter was unsuccessful. 2 errors, 0 warnings > > Well I haven't used Altera for a while, but it looks like an > EP1C12Q240C6 is a 240 pin PQFP and doesn't have a pin G1. > > Either you need to change the part or you need to change the pin. >=20 > Alan NishiokaArticle: 112401
Antii, My reply was intended for radarman who seems to be trying to simply update the "db" with the modified HEX files, to later re-create the SOF with quartus_asm. As for your original email, you are correct we do not have a way to update the SOF directly. Our flow assumes you are willing to use the "db" as the input. All I can say is that I am personally not aware of such request (until now). Your feedback is well received. -David Karchmer Altera Antti wrote: > dkarchmer@gmail.com schrieb: > > > Try the following from the command-line: > > > > quartus_cdb <rev> --update_mif > > quartus_asm <rev> > > > > where <rev> is the base name of your QSF file (i.e. the revision). > > > > The --update_mif should take the post-fit results and update any MIF > > and/or HEX file(s). You then run the assembler to re-generate the SOF. > > So, at least from the command-line, you do not need to do a full > > compile and you do not need smart recompile. > > > > If this does not work with HEX files (as it should), please file a > > service request or send me an email as we would need to debug and fix > > this. Thanks, > > > > -David Karchmer > > Altera > > > > dont worry so much - Xilinx has been fixing issues with their data2mem > for years and they still have not managed to get it right. > > well data2mem like tool is completly missing in Altera flow so Altera > cant have it wrong (as it is missing) > > > AnttiArticle: 112402
I found the thread about this kit but cannot write there, since it is more than 60 days old. I am seeking for an empty or small project to start with the xilinx ide. Of course I found the sample projects, but a) they are too complex IMO (i do not need the pico blaze yet ) and b) I am having difficulties in creating a complete and working project from out of the given files. To be honest, I am afraid of using a wrong configuration - esspeciall pin files - and then ruin my fpga! So if anybody has an "empty" project with correct settings (like unused pins z) and /or "z" definitions for the board (i think it is something as an ucf) I was happy if he could send me that. Thanks in advanceArticle: 112403
> 1 same size rquirement is BS, the tool should tolerate also different > sized blocks It should... however it doesn't.... > 2 and.. same size blocks dont work either, only first one gets PLACED, > second stays unprocessed > > so its just another Xilinx bug, Well, I do have a V4 design, which uses 4 consecutive 32KB BRAM blocks each attached through an individual PLB_BRAM controller and it works (last tried in 8.1)... Perhaps you are trying to do something more advanced... /MikhailArticle: 112404
spartanius@arcor.de wrote: > To be honest, I am afraid of using a wrong configuration - esspeciall > pin files - and then ruin my fpga! You can copy the UCF definition from the PDF documentation and then set an option (I forget which) in the IDE to ignore unconnected pins. > So if anybody has an "empty" project with correct settings (like unused > pins z) and /or "z" definitions for the board (i think it is something > as an ucf) I was happy if he could send me that. Not empty, but you can delete anything you don't need: http://www.frank-buss.de/vhdl/spartan3e.html Included on the web page: the non-intuitve steps required to synthesize it, starting and use of iMPACT :-) -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 112405
"MM" <mbmsv@yahoo.com> schrieb im Newsbeitrag news:4shb3eFvrarsU1@mid.individual.net... >> 1 same size rquirement is BS, the tool should tolerate also different >> sized blocks > > It should... however it doesn't.... > >> 2 and.. same size blocks dont work either, only first one gets PLACED, >> second stays unprocessed >> >> so its just another Xilinx bug, > > Well, I do have a V4 design, which uses 4 consecutive 32KB BRAM blocks > each > attached through an individual PLB_BRAM controller and it works (last > tried > in 8.1)... Perhaps you are trying to do something more advanced... > > > /Mikhail > > hm, i have two 64K blocks on LMB bus, and only first one is updated in the BMM file :( I dont think this is advanced use ? AnttiArticle: 112406
Grant Stockly wrote: > > If you are just trying to build a trainer of some sort, wouldn't it be > > easier to build a simulation that could show all the internal states? > > It has got to be easier to do a simulation than a construction project > > from transistors or even from CPLDs. > > I guess its because I'm in Alaska? The largest state in the union > mentality causes me to want to build a computer from transistors? :) > > I just find it so interesting that it can be done. Why not make a kit! > :) Wouldn't a second box under the altair with a few hundred lights > be neat to watch? > > I really want to build a computer from relays, and even priced out some > nice ones on e-bay, but I am concerned about how long it would last > before failing... One type of computer that might actually be interesting to build of relays and operate would be a time piece. To keep the power consumption down, you might use latching relays. The contain a permanet magnet that holds the contact in either state and a pulse from the coil is required to change the state. Each relay is then a FF. The logic would be done by stringing relays in series or parallel to form AND and OR functions (with or without inversions). You could also use diodes to form the logic if you want to save some space. There are some fairly minature relays available at around $5 or less. We are using some latching RF relays at that price. They are about 15 x 10 mm so a clock circuit might take up a square foot depending on the density. It would also tick every second with major noises on the minutes and hours. I am working on a relay controller circuit for an RF module and when I do the test code, it will have a few options to sound out tap dancing like music. That should prove interesting and entertaining!Article: 112407
PeteS wrote: > Ray Andraka wrote: > >> PeteS wrote: >> >>> Ray Andraka wrote: >>> >>>> John Larkin wrote: >>>> >>>> >>>>> >>>>> They should back off this religious devotion to fully synchronous >>>>> logic and give us a couple of dozen programmable true delay elements, >>>>> scattered about the chip. But they won't because it's not politically >>>>> correct, and because they figure that we're so dumb that we'd get into >>>>> trouble using them. >>>>> >>>>> >>>>> John >>>>> >>>> >>>> Virtex4 has them. They are the idelay elements, which give you 64 >>>> steps of delay with 75ps granularity. >>> >>> >>> >>> That's great, but for those of us using lower power [and on a lower >>> budget ;) ] devices, I could wish for the tools to obey my >>> requirements, but that would be a 'vendor specific solution' unless I >>> could get Verilog / VHDL changed to have a keyword where the >>> synthesis / PAR tools would understand that 'this is not to be >>> optimised in any way' on a perhaps module basis, rather than on a >>> global basis (WYSIWYG comes to mind). >>> >>> I've even gone to the extent of specifically instantiating >>> primitives, and PAR *still* optimises them out, even though there's >>> plenty of room for the logic, and I really wanted to do it that way >>> for various reasons. I do not want the tools to try and think for me; >>> software that tries to be that smart only succeeds in being dumb. I >>> have written a *lot* of software, and I learned that lesson the hard >>> way. >>> >>> As John already noted, the fervency around synchronous design is >>> almost religious. As I note in another post, it's preferable *most of >>> the time*, but there are times it actually prevents me from doing >>> things properly. One could hope the FPGA vendors and tool vendors >>> might listen to experienced pure hardware designers on this. >>> >>> Cheers >>> >>> PeteS >> >> >> If you really feel the need for async design, it can be done with >> utmost care on an FPGA, but such a design has to take into account the >> routing delays. The tools do not support specifying the routing >> delays beyond that needed to satisy synchronous operation, and for a >> very good reason (I'll address that in a moment). You can keep the >> tools from optimizing out pieces you need through addition of keep >> attributes. You can also instantiate primitives, which the tools >> generally do not remove (but you need to be careful with simple >> inversions or buffers), or you can create routed macros with FPGA >> editor. The hooks are there for manually doing your async design, and >> I have used them on the rare occasion. It is tedious and error prone, >> but everything you need to do it is there. >> >> That said, the FPGAs and tools are targeted to the sync design >> audience, as that is the bread and butter of the industry. The >> analysis and design is far easier to get correct with synchronous >> design rules, and as a result the tools are far easier to design and >> use for those cases. Since the synchronous design domain represents >> the large majority of all digital design, and the tools for doing it >> are lower hanging fruit than what is required for async design, it is >> natural the FPGA vendors only target that market, and to not have any >> interest in the async market. The cost to entry is too high: tools >> are much harder to design and verify, there are many more gotchas that >> need to be covered and tested for, there is a potential for far more >> technical support needs, and on top of all that a market that is less >> than a percent of the total market. Why would any sane vendor even >> pursue that when there are so many other easier to obtain ways to make >> money? > > > Thanks for answering, Ray :) > > I understand why the vendors don't specifically target the async market, > although I will say that the software developers who do the tools don't > always appear to truly understand hardware (it covers so many sins, I am > not surprised, nor is it a complaint, more an acknowledgment). Yup, I agree here. I really think the developers should be required to sit and use their tools on a design, but then they'd have to get up to speed on digital design first. > > As to making money, that is, to a great extent in any market, dependent > on customer goodwill. Making primitives that won't be optimised away and > not protecting me from myself when I so ask will make me far more likely > to use such a vendor again, because they have listened to my > requirements, and responded that such things are avialble. I take the > responsibility if it goes wrong, *provided* I get proper timing output > data from the tools. I'm not asking for autoplacement and guaranteed > constraint mapping, just a report that tells me the various timing > elements - then it's up to me. I'm not sure what you are looking for. You can dump speedprint if you really want to know the timing of elements (can you still do this, I haven't in several years). The timing of the logic is very well defined, but you'll also see that it varies depending on which pin is used. The timing of the routing is the fly in the ointment, because it typically represents 50% or more of the total timing between flip-flops in a synchronous design, and that route timing is of course quite sensitive to the exact route taken as well as to placement of the logic. Are you looking for a report of every route segment in the device? That is a huge report, not likely to be of much use. The static timing analyzer will report the timing of each element in a path, but the problem is combinatorial loops break it.Article: 112408
Hello For the I2C read, the step by step, the algorithm is: 1). write slave address+write bit 2). write register address 3). write slave addres+read bit 4). read After the end of step 2, and before step 3, you need to set the STA to indicate the real read. Note that STA is indicated by transition of HIGH to LOW on the SDA while SCL remains HIGH. I am wondering if there is minimum wait time between step 2 and beginning of step 3? Note that my design uses OpenCores' I2C (if it matters). Thanks. Happy Turkey Day, -MArticle: 112409
Ray Andraka wrote: > PeteS wrote: >> Ray Andraka wrote: >> >>> PeteS wrote: >>> >>>> Ray Andraka wrote: >>>> >>>>> John Larkin wrote: >>>>> >>>>> >>>>>> >>>>>> They should back off this religious devotion to fully synchronous >>>>>> logic and give us a couple of dozen programmable true delay elements, >>>>>> scattered about the chip. But they won't because it's not politically >>>>>> correct, and because they figure that we're so dumb that we'd get >>>>>> into >>>>>> trouble using them. >>>>>> >>>>>> >>>>>> John >>>>>> >>>>> >>>>> Virtex4 has them. They are the idelay elements, which give you 64 >>>>> steps of delay with 75ps granularity. >>>> >>>> >>>> >>>> That's great, but for those of us using lower power [and on a lower >>>> budget ;) ] devices, I could wish for the tools to obey my >>>> requirements, but that would be a 'vendor specific solution' unless >>>> I could get Verilog / VHDL changed to have a keyword where the >>>> synthesis / PAR tools would understand that 'this is not to be >>>> optimised in any way' on a perhaps module basis, rather than on a >>>> global basis (WYSIWYG comes to mind). >>>> >>>> I've even gone to the extent of specifically instantiating >>>> primitives, and PAR *still* optimises them out, even though there's >>>> plenty of room for the logic, and I really wanted to do it that way >>>> for various reasons. I do not want the tools to try and think for >>>> me; software that tries to be that smart only succeeds in being >>>> dumb. I have written a *lot* of software, and I learned that lesson >>>> the hard way. >>>> >>>> As John already noted, the fervency around synchronous design is >>>> almost religious. As I note in another post, it's preferable *most >>>> of the time*, but there are times it actually prevents me from doing >>>> things properly. One could hope the FPGA vendors and tool vendors >>>> might listen to experienced pure hardware designers on this. >>>> >>>> Cheers >>>> >>>> PeteS >>> >>> >>> If you really feel the need for async design, it can be done with >>> utmost care on an FPGA, but such a design has to take into account >>> the routing delays. The tools do not support specifying the routing >>> delays beyond that needed to satisy synchronous operation, and for a >>> very good reason (I'll address that in a moment). You can keep the >>> tools from optimizing out pieces you need through addition of keep >>> attributes. You can also instantiate primitives, which the tools >>> generally do not remove (but you need to be careful with simple >>> inversions or buffers), or you can create routed macros with FPGA >>> editor. The hooks are there for manually doing your async design, >>> and I have used them on the rare occasion. It is tedious and error >>> prone, but everything you need to do it is there. >>> >>> That said, the FPGAs and tools are targeted to the sync design >>> audience, as that is the bread and butter of the industry. The >>> analysis and design is far easier to get correct with synchronous >>> design rules, and as a result the tools are far easier to design and >>> use for those cases. Since the synchronous design domain represents >>> the large majority of all digital design, and the tools for doing it >>> are lower hanging fruit than what is required for async design, it is >>> natural the FPGA vendors only target that market, and to not have any >>> interest in the async market. The cost to entry is too high: tools >>> are much harder to design and verify, there are many more gotchas >>> that need to be covered and tested for, there is a potential for far >>> more technical support needs, and on top of all that a market that is >>> less than a percent of the total market. Why would any sane vendor >>> even pursue that when there are so many other easier to obtain ways >>> to make money? >> >> >> Thanks for answering, Ray :) >> >> I understand why the vendors don't specifically target the async >> market, although I will say that the software developers who do the >> tools don't always appear to truly understand hardware (it covers so >> many sins, I am not surprised, nor is it a complaint, more an >> acknowledgment). > > Yup, I agree here. I really think the developers should be required to > sit and use their tools on a design, but then they'd have to get up to > speed on digital design first. > >> >> As to making money, that is, to a great extent in any market, >> dependent on customer goodwill. Making primitives that won't be >> optimised away and not protecting me from myself when I so ask will >> make me far more likely to use such a vendor again, because they have >> listened to my requirements, and responded that such things are >> avialble. I take the responsibility if it goes wrong, *provided* I get >> proper timing output data from the tools. I'm not asking for >> autoplacement and guaranteed constraint mapping, just a report that >> tells me the various timing elements - then it's up to me. > > I'm not sure what you are looking for. You can dump speedprint if you > really want to know the timing of elements (can you still do this, I > haven't in several years). The timing of the logic is very well > defined, but you'll also see that it varies depending on which pin is > used. The timing of the routing is the fly in the ointment, because it > typically represents 50% or more of the total timing between flip-flops > in a synchronous design, and that route timing is of course quite > sensitive to the exact route taken as well as to placement of the logic. > Are you looking for a report of every route segment in the device? That > is a huge report, not likely to be of much use. The static timing > analyzer will report the timing of each element in a path, but the > problem is combinatorial loops break it. I want to know the static timing, no more, and I am aware it varies from pin to pin (well, duh). I am not asking for all possible routes. Here's something I would like; in the floorplanner - an identification of timing by route (single route only) so I could actually choose a specific signal route. ;and then lock it. Do-able? Cheers PeteSArticle: 112410
PeteS wrote: > > I want to know the static timing, no more, and I am aware it varies from > pin to pin (well, duh). I am not asking for all possible routes. > > Here's something I would like; in the floorplanner - an identification > of timing by route (single route only) so I could actually choose a > specific signal route. > > ;and then lock it. > > Do-able? > > Cheers > > PeteS Not in floorplanner, as floorplanner is a placement tool and is totally unaware of routing. You can do that in FPGA editor if you manually route rather than using autoroute. You can also create pre-routed macros this way.Article: 112411
Ray Andraka wrote: > PeteS wrote: > >> >> I want to know the static timing, no more, and I am aware it varies >> from pin to pin (well, duh). I am not asking for all possible routes. >> >> Here's something I would like; in the floorplanner - an identification >> of timing by route (single route only) so I could actually choose a >> specific signal route. >> >> ;and then lock it. >> >> Do-able? >> >> Cheers >> >> PeteS > > > Not in floorplanner, as floorplanner is a placement tool and is totally > unaware of routing. You can do that in FPGA editor if you manually > route rather than using autoroute. You can also create pre-routed > macros this way. Hmmm.... that opens up all sorts of new avenues (not to be told to the unwashed masses of course). Do those pre-routed macros get effectively locked? One would assume so, but I'll ask anyway. Thanks! PeteSArticle: 112412
thanks, but the synthesis sais "NgdBuild:755 - Line 7 in 'E:/xilinxprojekte/frankbuss/src/spartan3e.ucf':" for nearly all the lines up to 200x. (?Article: 112413
Joel Kolstad wrote: > John, > > "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message > news:1ejvl2d3j9tj96emac307rtjfr2l4o40q1@4ax.com... >> They should back off this religious devotion to fully synchronous >> logic and give us a couple of dozen programmable true delay elements, >> scattered about the chip. But they won't because it's not politically >> correct, and because they figure that we're so dumb that we'd get into >> trouble using them. > > I think the real problems are that: > > 1) It'd be difficult (read: expensive) for them to provide reasonably accurate > delay elements. With synchronous design, they just add a ring oscillator > somewhere and empirically determine how fast the thing will run, bin them > accordingly, and they're done! For delay elements... well, what are the > options? Laser trimming? Non-volatile tapped delay lines? Nothing that I > can think of that's dirt cheap. > > 2) You're correct, they do figure that "you" [as a whole] will get into > trouble using them. You -- personally -- clearly won't, but if you're running > a business it's clearly useful (to your bottom line!) to set up the system so > that you try to protect people who don't know what they're doing from blowing > their feet off. That being said, this approach is often taken too far to not > only keep a couple of the more advanced "doors" closed, but to put locks on > them altogether. I've seen software development tools go this route as > well -- they're perhaps improved and easier to use for novices, but actually > harder and less functional for experts. These days I have to hold my tongue > rather than go around claiming things aren't "expert friendly," because it is > seen as an attack somehow on the less-than-expert users. That's where the > political correctness BS comes into play! > > > Attack my ass If I can't gain complete access to the machine with a language, *I won't use it*. The fact that there are many who have no clue of what to do with it should not be an impediment to *my ability to develop solutions*. Sounds like an ID Ten T error to me Cheers PeteSArticle: 112414
spartanius@arcor.de wrote: > thanks, but the synthesis sais "NgdBuild:755 - Line 7 in > 'E:/xilinxprojekte/frankbuss/src/spartan3e.ucf':" for nearly all the > lines up to 200x. (? I also got there very elaborated messages on my design today. After digging some time, I realized, that nets "LOC"ed in the UCF did not exist in the HDL sources or had typing errors. But why the hell doesn't the error message tell that? -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 112415
Hello,
I know that it is possible to demodulate an FM signal using a CORDIC
ATAN core and the subtracting the current ouput of cordic from the last one.
But I can not understand how carrier frequency and sampling rate would
change it? What are the requirements? Where are the limitations?
Regards
Article: 112416Kumar, Please look at http://www.altera.com/literature/hb/qts/qts_qii53004.pdf Based on your baord requirements, you need to first spec your I/O timing requirements, and once you have them, you can use the assignment editor to enter the assignment. The document should help you understand the assignments for you to figure out your spec. As for an example for the assignment editor, here is one for Tsu - From Column: You can either enter the clock reference or leave empty - To Column: Enter the name of the pin you want to constraint - Assignmane Name: "Tsu Requirement" - Value: <value in ns> When you are done, click "Start Timing Analysis" and you should see the Tsu report show slack. In your QSF file, you will see something like set_instance_assignment -to mypin -name TSU_REQUIREMENT "5 ns" Hope this helps, -David Karchmer Altera ram wrote: > In the cyclone devices, > How to set parameters like tco,tsu,th,tpd.I am not using any M4K RAMS > or DSP blocks.I am using for LE_FF timing and LVTTl standards.I am not > using fast corner analysis.I have to fix up hold violations of no 96 I > referred cyclone II device data sheet DC and timing characteristics > page 106-135.How to set this paramters.There are no examples for > this.Can you provide examples for this.If you provide examples for this > in assignment editor ,it will be useful for users > kumarArticle: 112417
PeteS wrote: > Ray Andraka wrote: > >> PeteS wrote: >> >>> >>> I want to know the static timing, no more, and I am aware it varies >>> from pin to pin (well, duh). I am not asking for all possible routes. >>> >>> Here's something I would like; in the floorplanner - an >>> identification of timing by route (single route only) so I could >>> actually choose a specific signal route. >>> >>> ;and then lock it. >>> >>> Do-able? >>> >>> Cheers >>> >>> PeteS >> >> >> >> Not in floorplanner, as floorplanner is a placement tool and is >> totally unaware of routing. You can do that in FPGA editor if you >> manually route rather than using autoroute. You can also create >> pre-routed macros this way. > > > Hmmm.... that opens up all sorts of new avenues (not to be told to the > unwashed masses of course). Do those pre-routed macros get effectively > locked? One would assume so, but I'll ask anyway. > > Thanks! > > PeteS Yes. You can also generate routing directives that can go back into the ucf to direct routing, although those are specific to the location (ie, not hierarchical).Article: 112418
Hello, as many people over this world, I have a problem. The problem is the connection beetween a CPLD and the WEBPACK ISE 8.2.03 software. Simptoms like very static: I have an Parallel Cable III, the ISE software, and a XC9500XL family CPLD. The Impact cannot recognise the CPLD, for example a simple XC95144XL showed five unknown device in the JTAG chain on automatic JTAG chain initialize. I' has been tried to add the device manually, but there is not accepted as a result, because Impact answers unknown device ID. I'm told each family because tried with xc9536XL, simptoms are same. The cable is OK, I using it to program other devices (for example, XC3S400) on everyday. On software side, tried an older software (Xilinx Foundation 4) to program these devices, that programs all without problems. The question is what is the problem with ISE 8.2.03 ???Article: 112419
> One type of computer that might actually be interesting to build of > relays and operate would be a time piece. To keep the power > consumption down, you might use latching relays. The contain a > permanet magnet that holds the contact in either state and a pulse from > the coil is required to change the state. Each relay is then a FF. > The logic would be done by stringing relays in series or parallel to > form AND and OR functions (with or without inversions). You could also > use diodes to form the logic if you want to save some space. There are > some fairly minature relays available at around $5 or less. We are > using some latching RF relays at that price. They are about 15 x 10 mm > so a clock circuit might take up a square foot depending on the > density. It would also tick every second with major noises on the > minutes and hours. > > I am working on a relay controller circuit for an RF module and when I > do the test code, it will have a few options to sound out tap dancing > like music. That should prove interesting and entertaining! That is a pretty good idea. Would you have to use vaccume tubes with a crystal to generate the 1 second clock? (to maintain period technology) Now you have my head spinning...Its a good thing I'm done with the Altair! :) Before that I wanted to answer the question "What is the latency of a ping to a relay based computer?" My friends would hardly talk to me about that one. They think I'm crazy too. ALL the relays need to be the clear ice cube kind with the LED to indicate state. Or a separate LED I guess. I really like visual things. :)Article: 112420
Thank you..After I used xilinx's floorplan, I was able to fit it into 1 slice. Eric Crabill wrote: > Hello, > > What you expected is what the report said. I think you may have > misunderstood it. It has used 1 out of 4656 slices. The "Slice Flip Flops" > count is count of how many flip flops were used in your 1 slice. The > report could be a bit more clear, I think in the mapper report, this > relationship is more obvious due to the use of indentation in the text. > > EricArticle: 112421
On Mon, 20 Nov 2006 22:06:35 GMT, PeteS <peter.smith8380@ntlworld.com> wrote: >Ray Andraka wrote: >> John Larkin wrote: >> >> >>> >>> They should back off this religious devotion to fully synchronous >>> logic and give us a couple of dozen programmable true delay elements, >>> scattered about the chip. But they won't because it's not politically >>> correct, and because they figure that we're so dumb that we'd get into >>> trouble using them. >>> >>> >>> John >>> >> >> Virtex4 has them. They are the idelay elements, which give you 64 steps >> of delay with 75ps granularity. > >That's great, but for those of us using lower power [and on a lower >budget ;) ] devices, I could wish for the tools to obey my requirements, >but that would be a 'vendor specific solution' unless I could get >Verilog / VHDL changed to have a keyword where the synthesis / PAR tools >would understand that 'this is not to be optimised in any way' on a >perhaps module basis, rather than on a global basis (WYSIWYG comes to mind). > >I've even gone to the extent of specifically instantiating primitives, >and PAR *still* optimises them out, even though there's plenty of room >for the logic, and I really wanted to do it that way for various >reasons. I do not want the tools to try and think for me; software that >tries to be that smart only succeeds in being dumb. I have written a >*lot* of software, and I learned that lesson the hard way. > >As John already noted, the fervency around synchronous design is almost >religious. As I note in another post, it's preferable *most of the >time*, but there are times it actually prevents me from doing things >properly. One could hope the FPGA vendors and tool vendors might listen >to experienced pure hardware designers on this. > >Cheers > >PeteS We just solved a nasty problem with this: A d-flop: D tied high; clocked from a pin, CE from internal gating logic. Its Q output drives a BUFG clock net buffer, and Q also feeds a delay line back into its own async clear. When the input pin rises, if CE permits, it makes a single clock pulse. Everything downstream is "synchronous" in that it's clocked from this gadget. The delay line is a chain of AND gates (with transparent latches enabled in the logic cells, just to add a little more delay), with each fed from the ff Q and also from the previous gate. This is a delay line with a fast discharge mechanism when its input goes low, so we don't have to wait for the 0 to propagate through, chasing the 1. JohnArticle: 112422
Just one small clarification: Expresscard is not "equivalent" to PCIe: the connector actually provides both PCIe x1 and USB 2.0 ports, allowing each Expresscard slot to house either PCIe or USB based devices... or possibly both at once, should someone find a need for that. Since PCIe and USB are hotplug busses, they do not need the host controller glue logic Cardbus and PCMCIA required to bridge the void between hotplug cards and non-hotplug consumer PCI. John Adair wrote: > > Expresscard is mechanically incompatible and is basically a replacement > for PCMCIA/Cardbus and is the laptop equivalent of PCI-E. It is very > rapidly replacing PCMCIA/Cardbus in new laptops. > > John Adair > Enterpoint Ltd. > > vasile wrote: >> John Adair wrote: >>> Even if you implement Cardbus (essentially PCI) rather than >>> PCMCIA(essentially ISA) you won't get continuous 33MHz transfer other >>> than short periods of time. ExpressCard format can go this fast >>> providing the architecture behind it can support that data rate. >> Hi John, >> I didn't heard about this standard before. It's compatible with most >> PCMCIA interfaces >> available on laptops ? There is somewhere a documentation available ? >> >> thx, >> VasileArticle: 112423
spartanius@arcor.de wrote: > thanks, but the synthesis sais "NgdBuild:755 - Line 7 in > 'E:/xilinxprojekte/frankbuss/src/spartan3e.ucf':" for nearly all the > lines up to 200x. (? I can't reproduce this with the ise\Spartan3E.ise project file. If you've setup your own project, right-click on "Implement Design"->"Translate" and enable "Allow Unmatched LOC Constraints", if it is Uwe referenced. Do you use the latest version of ISE (help->about: 8.2.0.3i) ? Another interesting source of errors: ISE saves local settings for your projects in C:\Documents and Settings\YourName\Local Settings\Temp\something-with-ise-and-your-project-name Once I replaced the source files for my project, because I didn't want to setup all the settings again, but it didn't worked until I deleted the temporary files. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 112424
Hi, I have been having fun with I2C for a while. If you read the I2C specs, you will see that the same delays come up everywhere for any given bus speed. For 400kbps, this magic number is 600ns: SCL and SDA pulses must be 600ns wide minimum, a master should leave the bus idle for 600ns between transactions, SDA-to-SCL edges for start/stop should be at least 600ns apart, etc. Since the condition between your #2 and #3 should be a 'restart', there should usually not be any extra delays needed there, other than the usual 600ns SDA-to-SCL for start/stop conditions. Then again, many I2C devices have quirks that must be dealt with on a case-by-case basis. The opencores I2C master is somewhat odd: it seems that its designer forgot to provide some means of generating interrupts before the master outputs the ACK bit when reading a slave. Without this, the host has to divine whether or not the next byte received will be ACK'd. With that interrupt (and freezing SCL), the host would be able to make this (ACK) decision after receiving the byte. markus wrote: > Hello > > For the I2C read, the step by step, the algorithm is: > > 1). write slave address+write bit > 2). write register address > 3). write slave addres+read bit > 4). read > > After the end of step 2, and before step 3, you need to set the STA to > indicate the real read. Note that STA is indicated by transition of > HIGH to LOW on the SDA while SCL remains HIGH. I am wondering if there > is minimum wait time between step 2 and beginning of step 3? > > Note that my design uses OpenCores' I2C (if it matters). Thanks. > > Happy Turkey Day, > -M >
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